netdev - Re: [RFC] Defining a home/maintenance model for non-NIC PHC devices using the /dev/ptpX API

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <711e54ef-97db-4e01-b0d8-bcf2dea61fe6@linux.alibaba.com>
Date: Wed, 21 Jan 2026 22:20:28 +0800
From: Wen Gu <guwen@...ux.alibaba.com>
To: Manivannan Sadhasivam <mani@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
 Richard Cochran <richardcochran@...il.com>,
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
 LKML <linux-kernel@...r.kernel.org>, Jakub Kicinski <kuba@...nel.org>,
 Dust Li <dust.li@...ux.alibaba.com>, Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
 Andrew Lunn <andrew+netdev@...n.ch>, David Woodhouse <dwmw2@...radead.org>,
 virtualization@...ts.linux.dev, Nick Shi <nick.shi@...adcom.com>,
 Sven Schnelle <svens@...ux.ibm.com>, Paolo Abeni <pabeni@...hat.com>,
 linux-clk@...r.kernel.org
Subject: Re: [RFC] Defining a home/maintenance model for non-NIC PHC devices
 using the /dev/ptpX API



On 2026/1/19 22:48, Manivannan Sadhasivam wrote:
> Hi Wen,
> 
> On Fri, Jan 09, 2026 at 10:56:56AM +0800, Wen Gu wrote:
>>
>> Hi all,
>>
>> This is an RFC to discuss the appropriate upstream home and maintenance
>> model for a class of devices/drivers which expose a high-precision clock
>> to userspace via the existing PHC interface (/dev/ptpX + standard PTP_*
>> ioctls), but are not tied to a traditional NIC/IEEE1588 packet
>> timestamping pipeline.
>>
> 
> Thanks for starting the discussion. I sent out an email just today on this
> topic [1] and learned about this thread afterwards.

[...]

> 
> Some Qcom MHI devices expose the high precision clock derived from GNSS/Cellular
> network over the MHI registers and we recently sent out a series exposing them
> as PHC [2]. Since this driver is closely tied with MHI bus, we added it as a
> part of drivers/bus/mhi/.
> 
Hi Manivannan,

Thanks for the note and for sharing the MHI PHC use case.

Yes, this is very similar to what motivated this RFC, there are more and
more PHC providers which are not tied to NIC/IEEE 1588.

[...]

>>
>> Introducing a new clock type or a new userspace API (e.g. /dev/XXX) would
>> require widespread userspace changes, duplicated tooling, and long-term
>> fragmentation. This RFC is explicitly NOT proposing a new userspace API.
>>
> 
> +1
> 

[...]

> 
> If we get a consensus to move forward with exposing the device clocks as PHC, we
> will respin the MHI driver and would love to get an ACK from the (new)
> maintainers.
> 
> - Mani
> 
> [1] https://lore.kernel.org/all/vmwwnl3zv26lmmuqp2vqltg2fudalpc5jrw7k6ifg6l5cwlk3j@i7jm62zcsl67/
> [2] https://lore.kernel.org/mhi/20250818-tsc_time_sync-v1-0-2747710693ba@oss.qualcomm.com/
>