On Sun, 2026-01-04 at 14:11 +0800, Wen Gu wrote:

On 2026/1/3 03:51, Jakub Kicinski wrote:

quoted

On Mon, 22 Dec 2025 15:18:19 +0800 Wen Gu wrote:

quoted

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.

quoted

quoted

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.