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

[David Woodhouse]

On Mon, 2026-06-01 at 21:20 -0700, Richard Cochran wrote:
> 
> Sorry for replying to David here via Jakub's message.  Somehow my
> brilliant Gmail doesn't have David's reply...

Yeah, Gmail. Here's a nickel, kid... :)

> 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 wouldn't be the first, but yeah — more conventional would be to have
the core elsewhere and the drivers under linux/drivers/. 

That maybe involves moving the PTP core to kernel/time/ptp[/*] while
leaving the drivers where they are?

But first we have to know the problem we're trying to solve, and Jakub
has just revised my understanding of what he was originally asking for.

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

Ah, OK. Moderately confused because ines is the only one where I see
any evidence of hwtstamp support, and the rest just seem to provide a
PHC, but I'll take your word for it.

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

I think that assumption about the rate of patches should still be true.
If I end up owning a tree for the 'virt' drivers, I'd mostly be
answering "no, use VMClock instead". There's a reason I found a home
for that as a vendor-agnostic specification¹ and built the QEMU and
guest kernel support before even pushing it out at $DAYJOB.

¹ https://uapi-group.org/specifications/specs/vmclock/

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

I think that ties relatively well to Jakub's "does it purport to know
real time better than the host" criterion?

Although... ENA *both* purports to know real time better than the host
*and* does packet timestamping, and it looks like GVE is attempting to
do the same?

>    "Clock Devices" ?
>    linux/drivers/cd
> 
> Too short!
> 
>    "Time Keeping Devices" ?
>    linux/drivers/tkd
> 
> Confuses core time keeping!

That isn't necessarily a bad thing... (qv)

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

The key is that userspace wants to get snapshots of the reference clock
either precisely synchronized with the system clock where possible, or
sandwiched as closely together as possible with ABA readings of the
system, reference, system clock.

Those *are* the PTP_SYS_OFFSET* ioctls, which tools like chrony already
support with 'refclock PHC /dev/ptp…'.

I'm not sure how factoring those out into separate POSIX AUX clocks
would help? I think they do want to present as /dev/ptp*.

There is some extra stuff we want to do for "Precision RTCs" or
whatever we're going to call them. They might actually have a known TAI
offset, they might convey leap second indications, we might want to set
the kernel's CLOCK_REALTIME from them at boot. And in the case of
VMClock, I'm working on being able to clamp the kernel's timekeeping to
it directly².

So maybe what we want is linux/drivers/phc, to host those read-only
devices which know real time. They can provide a simplified
implementation; maybe *only* a function like vmclock_get_crosststamp(),
which is just called in various different permutations by the various
different PTP methods.

The core linux/drivers/phc code would then handle the interface to the
kernel's core timekeeping *and* wrap them to register a PTP device that
existing userspace can understand. And deal with the kvmclock/TSC
awfulness where needed.

How does that sound? 


² https://lore.kernel.org/all/20260520135207.37826-9-dwmw2@xxxxxxxxxxxxx/

Attachment: smime.p7s
Description: S/MIME cryptographic signature