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

[Wen Gu]

On 2026/2/27 18:25, David Woodhouse wrote:
> 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.

As mentioned in RFC v1, the use cases for drivers in the emulated PHC category
are expected to be quite diverse, and not limited to the virtualization/guest
time sync use case. For example, existing drivers such as ptp_ocp [1] and
upcoming ones such as mhi_phc [2] are not related to virtualization use cases.

The main motivation for this RFC is to find a clear in-tree home, upstreaming
path, and review/maintainership model for PHC/PTP drivers that use the existing
PTP userspace interface, but are not based on the IEEE 1588/network packet
timestamping pipeline, both for those already in the tree and for future
additions.

For virtualization-specific extensions (e.g. additional capabilities or ABI
changes), I agree they are valuable, but I think they are outside the scope of
this RFC series.

[1] https://lore.kernel.org/netdev/c85c77bc-9a8c-4336-ab79-89a981c43e01@xxxxxxxxx/
[2] https://lore.kernel.org/mhi/20250818-tsc_time_sync-v1-0-2747710693ba@xxxxxxxxxxxxxxxx/

> > # 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.

Thanks, David. It would be great to have you involved. Would you be willing to
be listed in MAINTAINERS for drivers/ptp/emulated/?

Regards.