Re: [PATCH net-next v5 1/2] ptp: introduce Alibaba CIPU PHC driver

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 2678 bytes --]

On Sun, 2026-01-04 at 14:11 +0800, Wen Gu wrote:
> 
> 
> On 2026/1/3 03:51, Jakub Kicinski wrote:
> > On Mon, 22 Dec 2025 15:18:19 +0800 Wen Gu wrote:
> > > The same applies to ptp_cipu, since it is already used and relies on
> > > exposing /dev/ptpX.
> > 
> > IIUC you mean that the driver is already used downstream and abandoning
> > PTP will break the OOT users? This is a non-argument upstream.
> > 
> 
> I know.
> 
> My point is that I hope ptp_cipu can use the PTP interface as these
> existing drivers, because many user programs and their ecosystems
> depend on the PTP interface, such as chrony, or other user programs
> based on `/dev/ptp*`. A new clock class device node will break this,
> requiring changes to all these user programs, otherwise they can't
> use the clock.
> 
> > > Given the historical baggage, it seems better to keep using the
> > > existing ptp framework, but separate these pure phc drivers into a
> > > new subsystem with a dedicated directory (e.g. drivers/phc/) and a
> > > MAINTAINERS entry, moving them out of the netdev maintenance scope.
> > > This should also address the concern that these pure phc drivers are
> > > not a good fit to be maintained under the networking subsystem.
> > 
> > I'd rather you left PTP completely alone with your funny read only
> > clocks. Please and thank you.
> 
> What you call 'funny' read only clocks have existed as PTP clocks for
> a long time, and there are many examples, such as ptp_kvm, ptp_vmw
> and ptp_s390. It also exists outside the drivers/ptp directory, such
> as drivers/hv/hv_util.c[1]. And there are also recent examples, such
> as drivers/virtio/virtio_rtc_ptp.c[2]. Even the PTP interface definition
> does not require that the ability to set the time must be supported.
> So I think the clock itself, as well as the use of the PTP interface
> is reasonable and not funny.
> 
> IIUC, the main block is that you don't want to maintain these pure
> phc clocks, as you mentioned in [3]. I agree with this as well. So I
> propose to group these pure phc drivers together (e.g. drivers/phc)
> and move them from the network maintenance domain to the clock maintenance
> domain.

I think that makes sense. These clocks can still be registered as PTP
clocks because that's one of the most sensible interfaces to userspace,
but the implementations can live elsewhere outside the networking
maintenance domain.

In a lot of cases we'd want to use them for RTC too, so that the
kernel's CLOCK_REALTIME can be initialised from them. And especially
for microvms I'd like to *synchronize* the kernel's clock from them
automatically too.



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]