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

[Richard Cochran <richardcochran@gmail.com>]

Sorry for replying to David here via Jakub's message.  Somehow my
brilliant Gmail doesn't have David's reply...

On Mon, Jun 01, 2026 at 06:52:26PM -0700, Jakub Kicinski wrote:
> On Mon, 01 Jun 2026 17:53:49 +0100 David Woodhouse wrote:
> > On Mon, 2026-06-01 at 08:20 -0700, Richard Cochran wrote:
> > > Sorry, just catching up here, so the idea is to have
> > > 
> > >  linux/drivers/ptp/drivers  ?  
> > 
> > That is my current suggestion.

drivers/../drivers seems a bit silly to me

> > 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/

The idea of categorizing core, NIC-related, vm, and stand alone clock
devices makes some sense to me.

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

So the whole in-kernel API in ptp_clock_kernel.h with ptp_clock_info,
etc, was poorly named (by me) back around Linux 3.0.  After all, the
abbreviation, "PTP", stands for a network protocol.  At the time, Alan
Cox pointed that out and complained, but somehow the code got merged
anyhow.

The term PHC is a better one, since PTP Hardware Clock means clock
device whose purpose is to support network time keeping together with
a NIC.

> > 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,

No, that is not quite right.  The clockmatrix, idt82p33, ines, and
qoriq drivers wouldn't be very useful without an attached NIC.

> > so perhaps we split those all out into
> > drivers/ptp/drivers/ and exclude them from the netdev maintenance?

Originally the idea was that the rate of patches would be low enough
that netdev would be the place to post and review them, and that no
separate tree or mailing list were needed. 

Even though the "PTP" naming was an unfortunate choice way back when,
still I'm not a big fan of moving stuff around "just because".

But moving forward, I would suggest starting a new area for pure
hardware clock devices.  

   "Clock Devices" ?
   linux/drivers/cd

Too short!

   "Time Keeping Devices" ?
   linux/drivers/tkd

Confuses core time keeping!

   "Advanced Clock Devices" ?
   linux/drivers/acd

Let's come up with a fitting name.

Still, I don't understand why these new (non-network related ) device
drivers can't be implemented in their own class using posix_clock_register()
etc.

Any of the useful bits (like sysfs interfaces) can be refactored out
of ptp_clock.c and shared as a common layer.

Thanks,
Richard