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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <de8952121036deb58c07be294a044b5ff5bc00f4.camel@infradead.org>
Date: Fri, 09 Jan 2026 10:25:51 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Wen Gu <guwen@...ux.alibaba.com>, Jakub Kicinski <kuba@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>, Richard Cochran
 <richardcochran@...il.com>, andrew+netdev@...n.ch, davem@...emloft.net, 
 edumazet@...gle.com, pabeni@...hat.com, xuanzhuo@...ux.alibaba.com, 
 dust.li@...ux.alibaba.com, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v5 1/2] ptp: introduce Alibaba CIPU PHC driver

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.



Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)