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

[Wen Gu <guwen@linux.alibaba.com>]

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.

What's your new concern?

[1] https://lore.kernel.org/all/20170130110716.16795-4-vkuznets@redhat.com/
[2] https://lore.kernel.org/all/20250509160734.1772-3-quic_philber@quicinc.com/
[3] https://lore.kernel.org/all/20251127083610.6b66a728@kernel.org/

Regards.