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

[Wen Gu]

On 2025/11/29 02:24, Jakub Kicinski wrote:
> On Fri, 28 Nov 2025 14:22:21 +0800 Wen Gu wrote:
> > > Could you go complain to clock people? Or virtualization people?
> >
> > I understand that the PTP implementations in drivers/ptp aren't closely
> > related to networking though drivers/ptp is included in NETWORKING DRIVERS
> > in the MAINTAINER file.
> >
> > I noticed that drivers/ptp/* is also inclued in PTP HARDWARE CLOCK SUPPORT.
> > This attribution seems more about 'clock'.
> >
> > Hi @Richard Cochran, could you please review this? Thanks! :)
>
> It's Thanksgiving weekend in the US, Richard may be AFK so excuse my
> speaking for him, but he mentioned in the past that he is also not
> interested in becoming a maintainer for general clocks, unrelated
> to PTP.

Wishing you a Happy Thanksgiving!

I think you misunderstood. I didn't encourage Richard to maintain
general clocks unrelated to PTP. Rather, I believe this driver should
belong to the PTP subsystem, and here are my reasons (which have been
mentioned in previous emails):

1. CIPU provides high-precision PHCs for VMs or bare metals, which
   are exposed as ptp_clock according to the definition in [1]. its
   usage is no different from other ptp devices. So this is a PTP
   driver.

[1] https://docs.kernel.org/driver-api/ptp.html

2. The PTP implementations that are independent of networking and
   NICs are placed under drivers/ptp. These devices are provided from
   chip/FPGA/hypervisor and maintain clock accuracy in their own unique
   ways. CIPU ptp driver is no different and should also be placed
   under the drivers/ptp from this perspective.

According to the MAINTAINERS file, drivers/ptp/* is maintained by the
NETWORKING DRIVERS and PTP HARDWARE CLOCK SUPPORT subsystems. Considering
you mentioned that drivers/ptp is not closely related to networking, I
think it might be more appropriate for the PTP HARDWARE CLOCK SUPPORT
subsystem maintainer to review it. After it merges into the upstream,
we will be its maintainers.

> Search the mailing list, there are at least 3 drivers like yours being
> proposed. Maybe you can get together with also the KVM and VMclock
> authors and form a new subsystem?

I think drivers under drivers/ptp are all similar. But aside from the
fact that they are all exposed as PTP devices and therefore classified
in the PTP subsystem, I haven't been able to find a way to classify
them into another class (note that CIPU ptp can't be considered a
VM/hypervisor clock class since bare metal scenario is also applicable).

Regards.