On 12/01/2026 11:00, Sven Schnelle wrote:

Hi Wen,

Wen Gu [off-list ref] writes:

quoted

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.