linux-kernel - 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: <6a32849d-6c7b-4745-b7f0-762f1b541f3d@linux.dev>
Date: Mon, 12 Jan 2026 12:15:19 +0000
From: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
To: Sven Schnelle <svens@...ux.ibm.com>, Wen Gu <guwen@...ux.alibaba.com>
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>,
 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 12/01/2026 11:00, Sven Schnelle wrote:
> Hi Wen,
> 
> Wen Gu <guwen@...ux.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.