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: <yt9decnv6qpc.fsf@linux.ibm.com>
Date: Mon, 12 Jan 2026 12:00:31 +0100
From: Sven Schnelle <svens@...ux.ibm.com>
To: 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

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.