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

[Vadim Fedorenko <vadim.fedorenko@linux.dev>]

On 12/01/2026 11:00, Sven Schnelle wrote:
> Hi Wen,
> 
> Wen Gu <guwen@linux.alibaba.com> writes:
> 
>> 1. Reorganize drivers/ptp/ to make the interface/implementation split
>>     explicit,
>>
>>     * drivers/ptp/core      : PTP core infrastructure and API.
>>                               (e.g. ptp_chardev.c, ptp_clock.c,
>>                                ptp_sysfs.c, etc.)
>>
>>     * drivers/ptp/pure      : Non-network ("pure clock") implementation,
>>                               they are typically platform/architecture/
>>                               virtualization-provided time sources.
>>                               (e.g. ptp_kvm, ptp_vmw, ptp_vmclock,
>>                                ptp_s390, etc.)
>>
>>     * drivers/ptp/*         : Network timestamping oriented implementation,
>>                               they primarily used together with IEEE1588
>>                               over the network.
>>                               (e.g. ptp_qoriq, ptp_pch, ptp_dp83640,
>>                                ptp_idt82p33 etc.)
> 
> I'm fine with splitting paths - but I would propose a different naming
> scheme as 'pure' is not really a common term in the driver world (at
> least in my perception, which might be wrong. How about the following
> instead:
> 
> drivers/ptp/core    - API as written above
> drivers/ptp/virtual - all PtP drivers somehow emulating a PtP clock
>                        (like the ptp_s390 driver)
> drivers/ptp/net     - all NIC related drivers.
> 


Well, drivers/ptp/virtual is not really good, because some drivers are
for physical devices exporting PTP interface, but without NIC.
Another way is to split physical board drivers to another category, like
drivers/ptp/hardware. The main difference to virtual is that these 
devices can output signals on external physical pins as well as
timestamp inputs on physical pins.