kernel/linux.git/drivers/ptp/Makefile, branch v6.19.11

ptp: qoriq: convert to use generic interfaces to set loopback mode

2025-09-10T02:28:52+00:00

Since the generic debugfs interfaces for setting the periodic pulse signal loopback have been added to the ptp_clock driver, so convert the vendor-defined debugfs interfaces to the generic interfaces. Signed-off-by: Wei Fang Reviewed-by: Vladimir Oltean Tested-by: Vladimir Oltean Link: https://patch.msgid.link/20250905030711.1509648-4-wei.fang@nxp.com Signed-off-by: Jakub Kicinski

ptp: netc: add NETC V4 Timer PTP driver support

2025-09-02T11:13:33+00:00

NETC V4 Timer provides current time with nanosecond resolution, precise periodic pulse, pulse on timeout (alarm), and time capture on external pulse support. And it supports time synchronization as required for IEEE 1588 and IEEE 802.1AS-2020. Inside NETC, ENETC can capture the timestamp of the sent/received packet through the PHC provided by the Timer and record it on the Tx/Rx BD. And through the relevant PHC interfaces provided by the driver, the enetc V4 driver can support PTP time synchronization. In addition, NETC V4 Timer is similar to the QorIQ 1588 timer, but it is not exactly the same. The current ptp-qoriq driver is not compatible with NETC V4 Timer, most of the code cannot be reused, see below reasons. 1. The architecture of ptp-qoriq driver makes the register offset fixed, however, the offsets of all the high registers and low registers of V4 are swapped, and V4 also adds some new registers. so extending ptp-qoriq to make it compatible with V4 Timer is tantamount to completely rewriting ptp-qoriq driver. 2. The usage of some functions is somewhat different from QorIQ timer, such as the setting of TCLK_PERIOD and TMR_ADD, the logic of configuring PPS, etc., so making the driver compatible with V4 Timer will undoubtedly increase the complexity of the code and reduce readability. 3. QorIQ is an expired brand. It is difficult for us to verify whether it works stably on the QorIQ platforms if we refactor the driver, and this will make maintenance difficult, so refactoring the driver obviously does not bring any benefits. Therefore, add this new driver for NETC V4 Timer. Note that the missing features like PEROUT, PPS and EXTTS will be added in subsequent patches. Signed-off-by: Wei Fang Reviewed-by: Frank Li Link: https://patch.msgid.link/20250829050615.1247468-5-wei.fang@nxp.com Signed-off-by: Paolo Abeni

s390/time: Add PtP driver

2024-10-31T00:02:39+00:00

Add a small PtP driver which allows user space to get the values of the physical and tod clock. This allows programs like chrony to use STP as clock source and steer the kernel clock. The physical clock can be used as a debugging aid to get the clock without any additional offsets like STP steering or LPAR offset. Acked-by: Heiko Carstens Acked-by: Richard Cochran Signed-off-by: Sven Schnelle Link: https://patch.msgid.link/20241023065601.449586-3-svens@linux.ibm.com Signed-off-by: Jakub Kicinski

ptp: Add support for the AMZNC10C 'vmclock' device

2024-10-09T11:16:18+00:00

The vmclock device addresses the problem of live migration with precision clocks. The tolerances of a hardware counter (e.g. TSC) are typically around ±50PPM. A guest will use NTP/PTP/PPS to discipline that counter against an external source of 'real' time, and track the precise frequency of the counter as it changes with environmental conditions. When a guest is live migrated, anything it knows about the frequency of the underlying counter becomes invalid. It may move from a host where the counter running at -50PPM of its nominal frequency, to a host where it runs at +50PPM. There will also be a step change in the value of the counter, as the correctness of its absolute value at migration is limited by the accuracy of the source and destination host's time synchronization. In its simplest form, the device merely advertises a 'disruption_marker' which indicates that the guest should throw away any NTP synchronization it thinks it has, and start again. Because the shared memory region can be exposed all the way to userspace through the /dev/vmclock0 node, applications can still use time from a fast vDSO 'system call', and check the disruption marker to be sure that their timestamp is indeed truthful. The structure also allows for the precise time, as known by the host, to be exposed directly to guests so that they don't have to wait for NTP to resync from scratch. The PTP driver consumes this information if present. Like the KVM PTP clock, this PTP driver can convert TSC-based cross timestamps into KVM clock values. Unlike the KVM PTP clock, it does so only when such is actually helpful. The values and fields are based on the nascent virtio-rtc specification, and the intent is that a version (hopefully precisely this version) of this structure will be included as an optional part of that spec. In the meantime, this driver supports the simple ACPI form of the device which is being shipped in certain commercial hypervisors (and submitted for inclusion in QEMU). Signed-off-by: David Woodhouse Acked-by: Richard Cochran Signed-off-by: David S. Miller

ptp: add FemtoClock3 Wireless as ptp hardware clock

2024-01-29T13:00:23+00:00

The RENESAS FemtoClock3 Wireless is a high-performance jitter attenuator, frequency translator, and clock synthesizer. The device is comprised of 3 digital PLLs (DPLL) to track CLKIN inputs and three independent low phase noise fractional output dividers (FOD) that output low phase noise clocks. FemtoClock3 supports one Time Synchronization (Time Sync) channel to enable an external processor to control the phase and frequency of the Time Sync channel and to take phase measurements using the TDC. Intended applications are synchronization using the precision time protocol (PTP) and synchronization with 0.5 Hz and 1 Hz signals from GNSS. Signed-off-by: Min Li Acked-by: Lee Jones Signed-off-by: David S. Miller

net: ptp: create a mock-up PTP Hardware Clock driver

2023-08-09T22:59:21+00:00

There are several cases where virtual net devices may benefit from having a PTP clock, and these have to do with testing. I can see at least netdevsim and veth as potential users of a common mock-up PTP hardware clock driver. The proposed idea is to create an object which emulates PTP clock operations on top of the unadjustable CLOCK_MONOTONIC_RAW plus a software-controlled time domain via a timecounter/cyclecounter and then link that PHC to the netdevsim device. The driver is fully functional for its intended purpose, and it successfully passes the PTP selftests. $ cd tools/testing/selftests/ptp/ $ ./phc.sh /dev/ptp2 TEST: settime [ OK ] TEST: adjtime [ OK ] TEST: adjfreq [ OK ] Signed-off-by: Vladimir Oltean Link: https://lore.kernel.org/r/20230807193324.4128292-7-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski

ptp: add ToD device driver for Intel FPGA cards

2023-03-30T04:25:48+00:00

Adding a DFL (Device Feature List) device driver of ToD device for Intel FPGA cards. The Intel FPGA Time of Day(ToD) IP within the FPGA DFL bus is exposed as PTP Hardware clock(PHC) device to the Linux PTP stack to synchronize the system clock to its ToD information using phc2sys utility of the Linux PTP stack. The DFL is a hardware List within FPGA, which defines a linked list of feature headers within the device MMIO space to provide an extensible way of adding subdevice features. Signed-off-by: Raghavendra Khadatare Signed-off-by: Tianfei Zhang Acked-by: Richard Cochran Reviewed-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20230328142455.481146-1-tianfei.zhang@intel.com Signed-off-by: Jakub Kicinski

ptp: add ptp virtual clock driver framework

2021-07-01T20:08:18+00:00

This patch is to add ptp virtual clock driver framework utilizing timecounter/cyclecounter. The patch just exports two essential APIs for PTP driver. - ptp_vclock_register() - ptp_vclock_unregister() Signed-off-by: Yangbo Lu Signed-off-by: David S. Miller

ptp: arm/arm64: Enable ptp_kvm for arm/arm64

2021-04-07T15:33:20+00:00

Currently, there is no mechanism to keep time sync between guest and host in arm/arm64 virtualization environment. Time in guest will drift compared with host after boot up as they may both use third party time sources to correct their time respectively. The time deviation will be in order of milliseconds. But in some scenarios,like in cloud environment, we ask for higher time precision. kvm ptp clock, which chooses the host clock source as a reference clock to sync time between guest and host, has been adopted by x86 which takes the time sync order from milliseconds to nanoseconds. This patch enables kvm ptp clock for arm/arm64 and improves clock sync precision significantly. Test result comparisons between with kvm ptp clock and without it in arm/arm64 are as follows. This test derived from the result of command 'chronyc sources'. we should take more care of the last sample column which shows the offset between the local clock and the source at the last measurement. no kvm ptp in guest: MS Name/IP address Stratum Poll Reach LastRx Last sample ======================================================================== ^* dns1.synet.edu.cn 2 6 377 13 +1040us[+1581us] +/- 21ms ^* dns1.synet.edu.cn 2 6 377 21 +1040us[+1581us] +/- 21ms ^* dns1.synet.edu.cn 2 6 377 29 +1040us[+1581us] +/- 21ms ^* dns1.synet.edu.cn 2 6 377 37 +1040us[+1581us] +/- 21ms ^* dns1.synet.edu.cn 2 6 377 45 +1040us[+1581us] +/- 21ms ^* dns1.synet.edu.cn 2 6 377 53 +1040us[+1581us] +/- 21ms ^* dns1.synet.edu.cn 2 6 377 61 +1040us[+1581us] +/- 21ms ^* dns1.synet.edu.cn 2 6 377 4 -130us[ +796us] +/- 21ms ^* dns1.synet.edu.cn 2 6 377 12 -130us[ +796us] +/- 21ms ^* dns1.synet.edu.cn 2 6 377 20 -130us[ +796us] +/- 21ms in host: MS Name/IP address Stratum Poll Reach LastRx Last sample ======================================================================== ^* 120.25.115.20 2 7 377 72 -470us[ -603us] +/- 18ms ^* 120.25.115.20 2 7 377 92 -470us[ -603us] +/- 18ms ^* 120.25.115.20 2 7 377 112 -470us[ -603us] +/- 18ms ^* 120.25.115.20 2 7 377 2 +872ns[-6808ns] +/- 17ms ^* 120.25.115.20 2 7 377 22 +872ns[-6808ns] +/- 17ms ^* 120.25.115.20 2 7 377 43 +872ns[-6808ns] +/- 17ms ^* 120.25.115.20 2 7 377 63 +872ns[-6808ns] +/- 17ms ^* 120.25.115.20 2 7 377 83 +872ns[-6808ns] +/- 17ms ^* 120.25.115.20 2 7 377 103 +872ns[-6808ns] +/- 17ms ^* 120.25.115.20 2 7 377 123 +872ns[-6808ns] +/- 17ms The dns1.synet.edu.cn is the network reference clock for guest and 120.25.115.20 is the network reference clock for host. we can't get the clock error between guest and host directly, but a roughly estimated value will be in order of hundreds of us to ms. with kvm ptp in guest: chrony has been disabled in host to remove the disturb by network clock. MS Name/IP address Stratum Poll Reach LastRx Last sample ======================================================================== * PHC0 0 3 377 8 -7ns[ +1ns] +/- 3ns * PHC0 0 3 377 8 +1ns[ +16ns] +/- 3ns * PHC0 0 3 377 6 -4ns[ -0ns] +/- 6ns * PHC0 0 3 377 6 -8ns[ -12ns] +/- 5ns * PHC0 0 3 377 5 +2ns[ +4ns] +/- 4ns * PHC0 0 3 377 13 +2ns[ +4ns] +/- 4ns * PHC0 0 3 377 12 -4ns[ -6ns] +/- 4ns * PHC0 0 3 377 11 -8ns[ -11ns] +/- 6ns * PHC0 0 3 377 10 -14ns[ -20ns] +/- 4ns * PHC0 0 3 377 8 +4ns[ +5ns] +/- 4ns The PHC0 is the ptp clock which choose the host clock as its source clock. So we can see that the clock difference between host and guest is in order of ns. Cc: Mark Rutland Acked-by: Richard Cochran Signed-off-by: Jianyong Wu Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20201209060932.212364-8-jianyong.wu@arm.com

ptp: Reorganize ptp_kvm.c to make it arch-independent

2021-04-07T15:33:07+00:00

Currently, the ptp_kvm module contains a lot of x86-specific code. Let's move this code into a new arch-specific file in the same directory, and rename the arch-independent file to ptp_kvm_common.c. Acked-by: Richard Cochran Reviewed-by: Andre Przywara Signed-off-by: Jianyong Wu Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20201209060932.212364-4-jianyong.wu@arm.com