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

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

On 2025/12/1 14:04, Wen Gu wrote:
> 
> 
> 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.


Given that net-next is closed and the EOY break is here, I was wondering
whether the review discussion might continue during this period or should
wait until after the break.

Thanks.