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

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/[email protected]/
[2] https://lore.kernel.org/mhi/[email protected]/

>> # Request for comments
>>
>> 1. Following the clocksource/timekeeping and POSIX timer areas, this RFC routes
>> changes for drivers/ptp/emulated/ to [email protected] (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.