Hi all,

This series follows the discussion in RFC v1 and RFC v2 [1-2].


# Background

The PTP Hardware Clock (PHC) interface (/dev/ptpX and the standard PTP_*
ioctls) was originally introduced for IEEE 1588 / network oriented clock
drivers. Over time, it has also become a common userspace API for many non-NIC
high-precision clock implementations (virtualization/platform/architecture
provided clocks) [3-7], and more are expected to appear [8-9].

During the review of these incoming non IEEE 1588 based PHC drivers, concerns
were raised that such "non-NIC" clocks may not be a good fit for the netdev
maintainership model [10], where PTP/PHC drivers are currently maintained.
This leaves an unclear upstream home and maintainership model for this class
of drivers.


# Proposal

This series proposes moving PHC drivers that expose a high-precision clock to
userspace via the existing PTP interface (/dev/ptpX + standard PTP_* ioctls),
but are not tied to the traditional NIC/IEEE 1588 packet timestamping
pipeline, out of the netdev maintenance domain and into the clock/timekeeping
maintenance domain.

As discussed in [1-2], this series makes the separation explicit by splitting
drivers/ptp/ into the following groups. This structure provides clearer
ownership and long-term maintenance boundaries:

  - drivers/ptp/          : PTP core infrastructure and userspace ABI
                            (ptp_clock.c, ptp_chardev.c, ptp_sysfs.c,
                             ptp_vclock.c, etc.) remain here.

  - drivers/ptp/ieee1588/ : network / IEEE 1588 oriented PTP drivers.

  - drivers/ptp/emulated/ : non IEEE 1588 PTP drivers. They are typically
                            platform/architecture/virtualization/special
                            hardware provided high-precision time sources.

Patch 1 performs the refactor: move drivers and split Kconfig/Makefiles
accordingly, without intended functional changes.

Patch 2 updates MAINTAINERS to match the new layout and adds a dedicated entry
for drivers/ptp/emulated/, moving review and ownership routing for this class
of drivers away from the netdev maintainership.

No userspace ABI changes are intended, this is a refactor and maintenance
metadata update only.


# Changes since RFC v2:

- Keep ptp_ocp under the IEEE1588/network-oriented PTP drivers as suggested
  by Jakub. 

- Following the model used by NTP related code, this series lists tip.git
  (timers/core) as the integration tree for emulated PTP clocks in the
  MAINTAINERS entry. Guidance from clock/timekeeping maintainers
  (Thomas Gleixner, John Stultz, Anna-Maria Behnsen, Frederic Weisbecker,
  Daniel Lezcano, Stephen Boyd) on whether this is the appropriate workflow
  for this class of drivers would be appreciated.

- Continue listing ourselves as maintainers for now as a fallback contact
  point. In the long term it would be preferable for this area to be
  maintained by clock/timekeeping experts, and suggestions are welcome.


Thanks for any input.

Regards.

[1] https://lore.kernel.org/all/0afe19db-9c7f-4228-9fc2-f7b34c4bc227@linux.alibaba.com/
[2] https://lore.kernel.org/all/20260227081934.96865-1-guwen@linux.alibaba.com/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a0e136d436ded817c0aade72efdefa56a00b4e5e
[4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7d10001e20e46ad6ad95622164686bc2cbfc9802
[5] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2d7de7a3010d713fb89b7ba99e6fdc14475ad106
[6] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3716a49a81ba19dda7202633a68b28564ba95eb5
[7] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9a17125a18f9ae1e1233a8e2d919059445b9d6fd
[8] https://lore.kernel.org/netdev/20251030121314.56729-1-guwen@linux.alibaba.com/
[9] https://lore.kernel.org/mhi/20250818-tsc_time_sync-v1-0-2747710693ba@oss.qualcomm.com/
[10] https://lore.kernel.org/netdev/20251127083610.6b66a728@kernel.org/

Wen Gu (2):
  ptp: split clock drivers into two subdirectories
  MAINTAINERS: update PTP maintainer entries after directory split

 MAINTAINERS                                  |  38 ++-
 drivers/ptp/Kconfig                          | 255 ++-----------------
 drivers/ptp/Makefile                         |  27 +-
 drivers/ptp/emulated/Kconfig                 |  61 +++++
 drivers/ptp/emulated/Makefile                |  11 +
 drivers/ptp/{ => emulated}/ptp_kvm_arm.c     |   0
 drivers/ptp/{ => emulated}/ptp_kvm_common.c  |   0
 drivers/ptp/{ => emulated}/ptp_kvm_x86.c     |   0
 drivers/ptp/{ => emulated}/ptp_s390.c        |   0
 drivers/ptp/{ => emulated}/ptp_vmclock.c     |   0
 drivers/ptp/{ => emulated}/ptp_vmw.c         |   0
 drivers/ptp/ieee1588/Kconfig                 | 179 +++++++++++++
 drivers/ptp/ieee1588/Makefile                |  16 ++
 drivers/ptp/{ => ieee1588}/ptp_clockmatrix.c |   0
 drivers/ptp/{ => ieee1588}/ptp_clockmatrix.h |   0
 drivers/ptp/{ => ieee1588}/ptp_dfl_tod.c     |   0
 drivers/ptp/{ => ieee1588}/ptp_dte.c         |   0
 drivers/ptp/{ => ieee1588}/ptp_fc3.c         |   0
 drivers/ptp/{ => ieee1588}/ptp_fc3.h         |   0
 drivers/ptp/{ => ieee1588}/ptp_idt82p33.c    |   0
 drivers/ptp/{ => ieee1588}/ptp_idt82p33.h    |   0
 drivers/ptp/{ => ieee1588}/ptp_ines.c        |   0
 drivers/ptp/{ => ieee1588}/ptp_mock.c        |   0
 drivers/ptp/{ => ieee1588}/ptp_netc.c        |   0
 drivers/ptp/{ => ieee1588}/ptp_ocp.c         |   0
 drivers/ptp/{ => ieee1588}/ptp_pch.c         |   0
 drivers/ptp/{ => ieee1588}/ptp_qoriq.c       |   0
 27 files changed, 322 insertions(+), 265 deletions(-)
 create mode 100644 drivers/ptp/emulated/Kconfig
 create mode 100644 drivers/ptp/emulated/Makefile
 rename drivers/ptp/{ => emulated}/ptp_kvm_arm.c (100%)
 rename drivers/ptp/{ => emulated}/ptp_kvm_common.c (100%)
 rename drivers/ptp/{ => emulated}/ptp_kvm_x86.c (100%)
 rename drivers/ptp/{ => emulated}/ptp_s390.c (100%)
 rename drivers/ptp/{ => emulated}/ptp_vmclock.c (100%)
 rename drivers/ptp/{ => emulated}/ptp_vmw.c (100%)
 create mode 100644 drivers/ptp/ieee1588/Kconfig
 create mode 100644 drivers/ptp/ieee1588/Makefile
 rename drivers/ptp/{ => ieee1588}/ptp_clockmatrix.c (100%)
 rename drivers/ptp/{ => ieee1588}/ptp_clockmatrix.h (100%)
 rename drivers/ptp/{ => ieee1588}/ptp_dfl_tod.c (100%)
 rename drivers/ptp/{ => ieee1588}/ptp_dte.c (100%)
 rename drivers/ptp/{ => ieee1588}/ptp_fc3.c (100%)
 rename drivers/ptp/{ => ieee1588}/ptp_fc3.h (100%)
 rename drivers/ptp/{ => ieee1588}/ptp_idt82p33.c (100%)
 rename drivers/ptp/{ => ieee1588}/ptp_idt82p33.h (100%)
 rename drivers/ptp/{ => ieee1588}/ptp_ines.c (100%)
 rename drivers/ptp/{ => ieee1588}/ptp_mock.c (100%)
 rename drivers/ptp/{ => ieee1588}/ptp_netc.c (100%)
 rename drivers/ptp/{ => ieee1588}/ptp_ocp.c (100%)
 rename drivers/ptp/{ => ieee1588}/ptp_pch.c (100%)
 rename drivers/ptp/{ => ieee1588}/ptp_qoriq.c (100%)

-- 
2.43.5

On Wed, Mar 18, 2026 at 12:33 AM Wen Gu <guwen@linux.alibaba.com> wrote:
> - Following the model used by NTP related code, this series lists tip.git
>   (timers/core) as the integration tree for emulated PTP clocks in the
>   MAINTAINERS entry. Guidance from clock/timekeeping maintainers
>   (Thomas Gleixner, John Stultz, Anna-Maria Behnsen, Frederic Weisbecker,
>   Daniel Lezcano, Stephen Boyd) on whether this is the appropriate workflow
>   for this class of drivers would be appreciated.

While I'm sure it would be good to continue to CC folks, I'm not sure
if the timekeeping maintainers would be the right folks for these
driver/ptp/ changes to flow through.
Thomas has been doing the heavy lifting for a long while and I'd not
want to put more on his shoulders.

Richard is listed as the maintainer for drivers/ptp/, is there any
reason for it not to go through him?

thanks
-john

On 2026/3/19 01:05, John Stultz wrote:
> On Wed, Mar 18, 2026 at 12:33 AM Wen Gu <guwen@linux.alibaba.com> wrote:
>> - Following the model used by NTP related code, this series lists tip.git
>>    (timers/core) as the integration tree for emulated PTP clocks in the
>>    MAINTAINERS entry. Guidance from clock/timekeeping maintainers
>>    (Thomas Gleixner, John Stultz, Anna-Maria Behnsen, Frederic Weisbecker,
>>    Daniel Lezcano, Stephen Boyd) on whether this is the appropriate workflow
>>    for this class of drivers would be appreciated.
> 
> While I'm sure it would be good to continue to CC folks, I'm not sure
> if the timekeeping maintainers would be the right folks for these
> driver/ptp/ changes to flow through.
> Thomas has been doing the heavy lifting for a long while and I'd not
> want to put more on his shoulders.
> 
> Richard is listed as the maintainer for drivers/ptp/, is there any
> reason for it not to go through him?
> 
> thanks
> -john

Hi John,

Thanks a lot for the feedback.

Richard is indeed listed as the maintainer for the PTP subsystem and
the traditional network-oriented PHC drivers. The intention of this
series is not to bypass that role. I would very much welcome Richard's
thoughts on the proposed split and the appropriate workflow for these
drivers.

Historically the PTP subsystem lived under networking because the
original PHC devices were tightly coupled with NIC hardware and the
IEEE1588 packet timestamping pipeline.

Over time, however, the PTP userspace interface (/dev/ptpX together
with the PTP_* ioctls) has also become a widely used way to expose
high-precision clocks to userspace. Because of the stable interface
and the existing ecosystem (e.g. chrony, phc2sys), many platform or
virtualization-provided clocks have started reusing the same PTP
interface.

As a result, drivers/ptp/ now contains two different classes of
devices: traditional network-oriented PHC drivers and clocks which
are not tied to the IEEE1588 networking pipeline.

The difficulty today is that there is no very clear upstream path for
this class of drivers: they currently live under drivers/ptp/, but
their design and review concerns are often closer to clock/timekeeping
topics than to networking. This series tries to find a clearer
upstream path and review route for this class of drivers.

Regarding the merge path, the suggestion about tip.git was mainly an
attempt to identify a possible integration tree for these drivers, but
I'm open to suggestions if there is a better workflow.

Thanks again for taking a look.

Wen Gu