Re: [RFC v2 0/2] ptp: Move non-NIC PHC drivers from netdev to clock/timekeeping maintainership

[David Woodhouse]

On Fri, 2026-02-27 at 16:19 +0800, Wen Gu wrote:
> 
> Patch 1 performs the refactor: move drivers and split Kconfig/Makefiles
> accordingly, without intended functional changes.
> 
> Patch 2 updates MAINTAINERS to match the new layout and adds a dedicated entry
> for drivers/ptp/emulated/, moving review and ownership routing for this class
> of drivers away from the netdev maintainership.
> 
> No userspace ABI changes are intended, this is a refactor and maintenance
> metadata update only.

While no ABI changes are intended in *this* patch series, we do need
some.

These 'emulated' clocks mostly exist not to emulate IEEE1588 per se,
but as a way to provide a precision real time clock to systems
(especially virtual guests).

We have already discussed the need to expose clock error bounds, and to
expose paired timestamps against the actual hardware counter (TSC, arch
counter, timebase, etc.).

Another key difference is that we'll generally want to be able to
derive UTC from these clocks, and feed them directly into the kernel's
CLOCK_REALTIME.

I don't have strong views on whether we extend the /dev/ptpX userspace
ABI, or start to treat these 'emulated' clocks as a class of device in
their own right and just shim them to /dev/ptpX for compatibility.

> # Request for comments
> 
> 1. Following the clocksource/timekeeping and POSIX timer areas, this RFC routes
> changes for drivers/ptp/emulated/ to linux-kernel@xxxxxxxxxxxxxxx (rather than
> netdev). However, the preferred integration path is still unclear (e.g. which
> tree should take such changes, and who should collect/pull them for merging). We
> would really appreciate guidance from the time/clock maintainers, especially any
> input from Thomas Gleixner, on the preferred tree/workflow for these changes.
> 
> 2. This RFC currently lists us as the maintainers for drivers/ptp/emulated/ as a
> fallback contact point. Ideally, we would prefer this area to be maintained by
> clock/time experts in the long run. Suggestions on more suitable maintainers are
> very welcome.

I'm happy to be involved too.

Attachment: smime.p7s
Description: S/MIME cryptographic signature