kernel/drivers/ptp/ptp_clock.c, branch linux-rolling-stable

ptp: Return -EINVAL on ptp_clock_register if required ops are NULL

2025-11-06T01:39:17Z

ptp_clock should never be registered unless it stubs one of gettimex64() or gettime64() and settime64(). WARN_ON_ONCE and error out if either set of function pointers is null. For consistency, n_alarm validation is also folded into the WARN_ON_ONCE. Suggested-by: Kuniyuki Iwashima Reviewed-by: Kuniyuki Iwashima Reviewed-by: Harshitha Ramamurthy Reviewed-by: Vadim Fedorenko Signed-off-by: Tim Hostetler Acked-by: Richard Cochran Link: https://patch.msgid.link/20251104225915.2040080-1-thostet@google.com Signed-off-by: Jakub Kicinski

ptp: rework ptp_clock_unregister() to disable events

2025-09-17T22:04:09Z

The ordering of ptp_clock_unregister() is not ideal, as the chardev remains published while state is being torn down, which means userspace can race with the kernel teardown. There is also no cleanup of enabled pin settings nor of the internal PPS event, which means enabled events can still forward into the core, dereferencing a free'd pointer. Rework the ordering of cleanup in ptp_clock_unregister() so that we unpublish the posix clock (and user chardev), disable any pins that have EXTTS events enabled, disable the PPS event, and then clean up the aux work and PPS source. This avoids potential use-after-free and races in PTP clock driver teardown. Signed-off-by: Russell King (Oracle) Reviewed-by: Vladimir Oltean Tested-by: Vladimir Oltean # ocelot, sja1105, netdevsim, vclocks Reviewed-by: Vadim Fedorenko Acked-by: Richard Cochran Link: https://patch.msgid.link/E1uydLH-000000061DM-2gcV@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski

ptp: add debugfs interfaces to loop back the periodic output signal

2025-09-10T02:28:52Z

For some PTP devices, they have the capability to loop back the periodic output signal for debugging, such as the ptp_qoriq device. So add the generic interfaces to set the periodic output signal loopback, rather than each vendor having a different implementation. Show how many channels support the periodic output signal loopback: $ cat /sys/kernel/debug/ptp/n_perout_loopback Enable the loopback of the periodic output signal of channel X: $ echo 1 > /sys/kernel/debug/ptp/perout_loopback Disable the loopback of the periodic output signal of channel X: $ echo 0 > /sys/kernel/debug/ptp/perout_loopback Suggested-by: Andrew Lunn Signed-off-by: Wei Fang Link: https://patch.msgid.link/20250905030711.1509648-2-wei.fang@nxp.com Signed-off-by: Jakub Kicinski

ptp: add helpers to get the phc_index by of_node or dev

2025-09-02T11:13:33Z

Some Ethernet controllers do not have an integrated PTP timer function. Instead, the PTP timer is a separated device and provides PTP hardware clock to the Ethernet controller to use. Therefore, the Ethernet controller driver needs to obtain the PTP clock's phc_index in its ethtool_ops::get_ts_info(). Currently, most drivers implement this in the following ways. 1. The PTP device driver adds a custom API and exports it to the Ethernet controller driver. 2. The PTP device driver adds private data to its device structure. So the private data structure needs to be exposed to the Ethernet controller driver. When registering the ptp clock, ptp_clock_register() always saves the ptp_clock pointer to the private data of ptp_clock::dev. Therefore, as long as ptp_clock::dev is obtained, the phc_index can be obtained. So the following generic APIs can be added to the ptp driver to obtain the phc_index. 1. ptp_clock_index_by_dev(): Obtain the phc_index by the device pointer of the PTP device. 2.ptp_clock_index_by_of_node(): Obtain the phc_index by the of_node pointer of the PTP device. Also, we can add another API like ptp_clock_index_by_fwnode() to get the phc_index by fwnode of PTP device. However, this API is not used in this patch set, so it is better to add it when needed. Suggested-by: Vladimir Oltean Signed-off-by: Wei Fang Reviewed-by: Frank Li Link: https://patch.msgid.link/20250829050615.1247468-4-wei.fang@nxp.com Signed-off-by: Paolo Abeni

ptp: Limit time setting of PTP clocks

2025-09-01T20:03:37Z

Networking drivers implementing PTP clocks and kernel socket code handling hardware timestamps use the 64-bit signed ktime_t type counting nanoseconds. When a PTP clock reaches the maximum value in year 2262, the timestamps returned to applications will overflow into year 1667. The same thing happens when injecting a large offset with clock_adjtime(ADJ_SETOFFSET). The commit 7a8e61f84786 ("timekeeping: Force upper bound for setting CLOCK_REALTIME") limited the maximum accepted value setting the system clock to 30 years before the maximum representable value (i.e. year 2232) to avoid the overflow, assuming the system will not run for more than 30 years. Enforce the same limit for PTP clocks. Don't allow negative values and values closer than 30 years to the maximum value. Drivers may implement an even lower limit if the hardware registers cannot represent the whole interval between years 1970 and 2262 in the required resolution. Signed-off-by: Miroslav Lichvar Cc: Richard Cochran Cc: Thomas Gleixner Cc: John Stultz Cc: Arnd Bergmann Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20250828103300.1387025-1-mlichvar@redhat.com Signed-off-by: Jakub Kicinski

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2025-06-19T20:00:24Z

Cross-merge networking fixes after downstream PR (net-6.16-rc3). No conflicts or adjacent changes. Signed-off-by: Jakub Kicinski

ptp: allow reading of currently dialed frequency to succeed on free-running clocks

2025-06-17T23:13:09Z

There is a bug in ptp_clock_adjtime() which makes it refuse the operation even if we just want to read the current clock dialed frequency, not modify anything (tx->modes == 0). That should be possible even if the clock is free-running. For context, the kernel UAPI is the same for getting and setting the frequency of a POSIX clock. For example, ptp4l errors out at clock_create() -> clockadj_get_freq() -> clock_adjtime() time, when it should logically only have failed on actual adjustments to the clock, aka if the clock was configured as slave. But in master mode it should work. This was discovered when examining the issue described in the previous commit, where ptp_clock_freerun() returned true despite n_vclocks being zero. Fixes: 73f37068d540 ("ptp: support ptp physical/virtual clocks conversion") Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20250613174749.406826-3-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski

ptp: Use ratelimite for freerun error message

2025-06-16T22:10:28Z

Replace pr_err() with pr_err_ratelimited() in ptp_clock_settime() to prevent log flooding when the physical clock is free running, which happens on some of my hosts. This ensures error messages are rate-limited and improves kernel log readability. Signed-off-by: Breno Leitao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250613-ptp-v1-1-ee44260ce9e2@debian.org Signed-off-by: Jakub Kicinski

ptp: Ensure info->enable callback is always set

2025-01-27T22:29:25Z

The ioctl and sysfs handlers unconditionally call the ->enable callback. Not all drivers implement that callback, leading to NULL dereferences. Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c. Instead use a dummy callback if no better was specified by the driver. Fixes: d94ba80ebbea ("ptp: Added a brand new class driver for ptp clocks.") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh Acked-by: Richard Cochran Reviewed-by: Michal Swiatkowski Link: https://patch.msgid.link/20250123-ptp-enable-v1-1-b015834d3a47@weissschuh.net Signed-off-by: Jakub Kicinski

treewide: Introduce kthread_run_worker[_on_cpu]()

2025-01-08T17:15:03Z

kthread_create() creates a kthread without running it yet. kthread_run() creates a kthread and runs it. On the other hand, kthread_create_worker() creates a kthread worker and runs it. This difference in behaviours is confusing. Also there is no way to create a kthread worker and affine it using kthread_bind_mask() or kthread_affine_preferred() before starting it. Consolidate the behaviours and introduce kthread_run_worker[_on_cpu]() that behaves just like kthread_run(). kthread_create_worker[_on_cpu]() will now only create a kthread worker without starting it. Signed-off-by: Frederic Weisbecker Signed-off-by: Dan Carpenter