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

[David Woodhouse]

On Tue, 2026-06-02 at 22:03 +0800, Wen Gu wrote:
> 
> > 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?
> > 
> 
> I think a dedicated phc core would make the classification of read-only
> clocks clearer, reducing ambiguity around where they belong. I assume
> direct timekeeping integration would be optional, drivers providing
> only a snapshot-based crosststamp would use /dev/ptpX alone, while the
> timekeeping path would require additional capability (as vmclock provides)?

Yeah. I think they might all want to be able to opt in to setting the
time at boot? But actually setting the fine-tuning of the kernel's
timekeeper is probably only something vmclock can do.

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