Re: [PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split

[Wen Gu <guwen@linux.alibaba.com>]

On 2026/6/2 00:53, David Woodhouse wrote:
> On Mon, 2026-06-01 at 08:20 -0700, Richard Cochran wrote:
>> On Mon, Jun 01, 2026 at 08:03:26AM +0100, David Woodhouse wrote:
>>> If we move all the plain non-network PHC drivers (which, as noted,
>>> is
>>> basically *all* of them) into a drivers/ subdirectory, then perhaps
>>> we
>>
>> Sorry, just catching up here, so the idea is to have
>>
>>   linux/drivers/ptp/drivers  ?
> 
> That is my current suggestion.
> 
> It stems from Jakub's response in
> https://lore.kernel.org/all/20250815113814.5e135318@kernel.org/ that "I
> really wish someone stepped up and created a separate subsystem for all
> these cloud / vm clocks. They have nothing to do with PTP."
> 
> There was some further bikeshedding in
> https://lore.kernel.org/netdev/0afe19db-9c7f-4228-9fc2-f7b34c4bc227@linux.alibaba.com/
> around how to split 'emulated' from other hardware drivers, but I don't
> much like that taxonomy. Some of these "virtual" clocks could just as
> easily exist in hardware with PTM too.
> 
> My observation is that with the sole exception of ptp_inet.c, *all* of
> the actual PHC drivers that live in drivers/ptp instead of drivers/net
> are "pure clock" drivers, so perhaps we split those all out into
> drivers/ptp/drivers/ and exclude them from the netdev maintenance?
> 

I think we don't need to split out all of them. The motivation was
to find an appropriate home for the PHC drivers that are read-only
and not disciplined by the host (ptp_vmw, ptp_vmclock, ptp_s390 and
the newly proposed ptp_cipu); they have little to do with networking.
The others are adjustable and tied to the network synchronization
stack (e.g. ptp4l); netdev is the right home for them.

My view is similar to Jakub's: the dividing line is whether the clock
provides authoritative time to the host and does not need to be
disciplined by it.

   Class A -- stays under netdev:
   - has its own physical counter/oscillator;
   - is adjustable (adjfine/adjtime/settime).

   Class B -- to be split out:
   - its time is maintained by an external source (hypervisor, DPU/IPU,
     or platform/arch);
   - the host side can only read it, not adjust it.

I will also adjust the relevant wording in the patch set accordingly,
dropping terms such as "non-NIC", "networking" and "IEEE 1588".

On the category name: the drivers we are splitting out only
provide time readout and do not support host discipline -- they behave
like a partial PHC. From that angle I think 'emulated' is defensible,
but I am also open to a better alternative.

> I'm reluctantly prepared to host and help maintain a drivers tree if
> it's necessary, but equally as happy to let you own it.
> 
> 

Thanks.