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

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

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