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.

Examples already in the tree include (non-exhaustive):

- drivers/ptp/ptp_kvm.c [1]
- drivers/ptp/ptp_vmw.c [2]
- drivers/ptp/ptp_s390.c [3]

There are also examples living in their respective subsystem (out of
scope for this RFC),
e.g. drivers/hv/hv_util.c [4] and drivers/virtio/virtio_rtc_ptp.c [5].

We (Alibaba Cloud) also posted a driver for a CIPU-provided high-precision
clock for review [6]. Based on existing in-tree precedent, we placed it
under drivers/ptp/ and sent it to the netdev list.

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

During review, concerns were raised that such "non-NIC / pure" PHC drivers
are not a good fit for netdev maintainership [7], since they are primarily
time/clock devices rather than networking protocol features.

As a result, I’m sending this RFC to align on a consistent upstream home
and maintainer model for this class of drivers, both for the existing ones
and future additions.

#
## Observation 1: PHC core/API are already not bound to NIC/IEEE1588
#

Although PHC support is original associated with NIC-based IEEE 1588
timestamping, the kernel tree already contains multiple non-NIC PHC
implementations (examples above), including long-standing and recently
added drivers. This reflects the reality that the PHC interface is no
longer tightly bound to NIC/IEEE1588 implementations.

This is enabled by the PHC interface's clean design, it provides a
well-scoped, layered abstraction that separates the userspace access
mechanism (/dev/ptpX + standard ioctl semantics) from the underlying
clock implementation and discipline method (NIC/IEEE1588 packet timestamping
pipeline, virtualization-provided clocks, platform/firmware time services,
etc.). The interface defines only generic clock-operation semantics, without
baking in assumptions about how the clock is produced or synchronized.

Because of this elegant decoupling, the PHC API naturally fits
"pure time source" devices as long as they can provide a stable, precise
hardware clock. In practice, PHC has effectively become Linux’s common
API for high-precision device clocks, rather than inherently bound to
an IEEE1588 NIC implementation.

#
## Observation 2: the PHC (/dev/ptpX) has an established userspace ecosystem
#

The PHC character device interface (/dev/ptpX + standard PTP_* ioctls) is
a mature, stable, and widely deployed userspace API for accessing
high-precision clocks on Linux. It is already the common interface consumed
by existing software stacks (e.g. chrony, and other applications built around
PHC devices)

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

#
## Goal
#

Establish an appropriate upstream home and maintainer model for "pure time
source" PHC drivers. If they are not suitable to be maintained under netdev,
we need a clear place and maintainer(s) for them, and a consistent policy
for accepting new ones.

#
## Proposal
#

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.)

2. Transition drivers/ptp/pure from netdev maintainership to
   clock/time maintainership (with an appropriate MAINTAINERS entry,
   e.g. PURE TIME PHC), since these PHC implementations are primarily
   clock devices and not network-oriented. New similar drivers can be
   added under drivers/ptp/pure as well.


Possible alternatives (please suggest others):

- Move/align "pure time source" PHC drivers under an existing
  timekeeping/clocksource/virt area, without changing the userspace API.


I’d like to drive this discussion towards consensus, and I’m happy to
adapt our series to match whatever direction is agreed upon.

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/ (local)
[2] https://lore.kernel.org/mhi/20250818-tsc_time_sync-v1-0-2747710693ba@oss.qualcomm.com/ (local)

-- 
மணிவண்ணன் சதாசிவம்