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

[Jakub Kicinski]

On Mon, 01 Jun 2026 17:53:49 +0100 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@xxxxxxxxxx/ 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@xxxxxxxxxxxxxxxxx/
> 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.

Not sure I fully understand what you mean. Practically the distinction
is very clear - the virt devices are implemented by a hypervisor and/or
IPU which may have some HW gadgets and PTM support but beyond that are
software-defined. We don't need help maintaining drivers for
fixed-ASIC (?) clocks, atomic clocks etc. Those are usually time
counter + misc. They are not "devices" which know the wall clock time
better than the host :\

IOW the "does it have a NIC" is not a great distinction.
A better oneliner would be "does it purport to know real time better 
than the host"

> 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'm reluctantly prepared to host and help maintain a drivers tree if
> it's necessary, but equally as happy to let you own it. 

No strong feelings here, but atomic clocks will start spilling into
DPLL and SyncE pretty quickly.