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 for Android: free password hash cracker in your pocket

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

Message-ID: <028dc6e9-c15a-4258-b72f-a4efe95503cc@linux.alibaba.com>
Date: Mon, 12 Jan 2026 11:45:37 +0800
From: Wen Gu <guwen@...ux.alibaba.com>
To: David Woodhouse <dwmw2@...radead.org>, 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 2026/1/9 17:25, David Woodhouse wrote:
> On Sun, 2026-01-04 at 14:11 +0800, Wen Gu wrote:
>>
>> 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.
> 

Yes. The PTP interface has become a common choice for exposing these
clocks to userspace, and it is not limited to NIC-based implementations.

I have posted an RFC to reach a consensus on organizing these clocks:

https://lore.kernel.org/netdev/0afe19db-9c7f-4228-9fc2-f7b34c4bc227@linux.alibaba.com/

> 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.
> 

This is also a good use-case that supports having these clocks available.

Regards.