[PATCH v2 0/2] ptp: split non-NIC PHC drivers into the clock/timekeeping maintenance domain

[PATCH v2 0/2] ptp: split non-NIC PHC drivers into the clock/timekeeping maintenance domain

[Wen Gu]

Hi all,

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


# 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 userspace API for many non-NIC
high-precision clock implementations (virtualization/platform/architecture
provided clocks) [4-8], and more are expected to appear [9-10].

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 [11], 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 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 [3], this series makes the separation explicit by reorganizing
the drivers/ptp/ layout into the following groups. This provides clearer
ownership and long-term maintenance boundaries:

  - drivers/ptp/          : PTP core infrastructure and
                            network / IEEE 1588 oriented PTP drivers.

  - drivers/ptp/emulated/ : emulated/virtual 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 Patch v1:

- List David Woodhouse as the maintainer of emulated PTP drivers.

- Adjust the directory layout: instead of creating both ieee1588/ and
  emulated/ subdirectories, keep the network-oriented drivers in the
  main drivers/ptp/ directory and only split out the emulated drivers.


# 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://lore.kernel.org/all/20260318073330.115808-1-guwen@linux.alibaba.com/
[4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a0e136d436ded817c0aade72efdefa56a00b4e5e
[5] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7d10001e20e46ad6ad95622164686bc2cbfc9802
[6] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2d7de7a3010d713fb89b7ba99e6fdc14475ad106
[7] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3716a49a81ba19dda7202633a68b28564ba95eb5
[8] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9a17125a18f9ae1e1233a8e2d919059445b9d6fd
[9] https://lore.kernel.org/netdev/20251030121314.56729-1-guwen@linux.alibaba.com/
[10] https://lore.kernel.org/mhi/20250818-tsc_time_sync-v1-0-2747710693ba@oss.qualcomm.com/
[11] https://lore.kernel.org/netdev/20251127083610.6b66a728@kernel.org/

Wen Gu (2):
  ptp: move emulated/virtual clock drivers into a dedicated subdirectory
  MAINTAINERS: update PTP maintainer entries after directory split

 MAINTAINERS                                 | 21 +++++--
 drivers/ptp/Kconfig                         | 68 ++++-----------------
 drivers/ptp/Makefile                        | 11 ++--
 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
 11 files changed, 103 insertions(+), 69 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%)

-- 
2.43.5

[PATCH v2 1/2] ptp: move emulated/virtual clock drivers into a dedicated subdirectory

[Wen Gu]

The PTP subsystem has grown beyond the original IEEE 1588/NIC use case
and today contains both network-oriented PHC drivers and various
emulated/virtual clock implementations.

Prepare for clearer ownership and future maintenance by moving the
emulated/virtual/non-NIC PTP clock drivers into a dedicated subdirectory,
with its own Kconfig and Makefile.

The network/IEEE 1588 oriented drivers remain in drivers/ptp/ alongside
the PTP core infrastructure:

  - drivers/ptp/          : PTP core infrastructure and IEEE 1588 /
                            network-oriented clock drivers.

  - drivers/ptp/emulated/ : emulated/virtual/non-NIC implementations
                            that expose high-precision time sources via
                            the PTP interface but are not tied to the
                            NIC/packet-timestamping pipeline.

No functional changes are intended; this is a refactor only.

Signed-off-by: Wen Gu <guwen@linux.alibaba.com>
---
 drivers/ptp/Kconfig                         | 68 ++++-----------------
 drivers/ptp/Makefile                        | 11 ++--
 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
 10 files changed, 87 insertions(+), 64 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%)

diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig
index b93640ca08b7..4cb199332546 100644
--- a/drivers/ptp/Kconfig
+++ b/drivers/ptp/Kconfig
@@ -20,11 +20,16 @@ config PTP_1588_CLOCK
 	  time stamping units, it can be possible to achieve
 	  synchronization to within a few hundred nanoseconds.
 
-	  This driver adds support for PTP clocks as character
-	  devices. If you want to use a PTP clock, then you should
-	  also enable at least one clock driver as well.
+	  This infrastructure adds support for PTP clocks as character
+	  devices. It has since evolved into a general-purpose PTP
+	  clock framework also used by high-precision clocks exposed
+	  by platforms, hypervisors or special hardware, beyond the
+	  traditional NIC/IEEE 1588 use case.
 
-	  To compile this driver as a module, choose M here: the module
+	  If you want to use any PTP clock device, enable this option
+	  and at least one clock driver.
+
+	  To compile the core as a module, choose M here: the module
 	  will be called ptp.
 
 config PTP_1588_CLOCK_OPTIONAL
@@ -119,35 +124,6 @@ config PTP_1588_CLOCK_PCH
 	  To compile this driver as a module, choose M here: the module
 	  will be called ptp_pch.
 
-config PTP_1588_CLOCK_KVM
-	tristate "KVM virtual PTP clock"
-	depends on PTP_1588_CLOCK
-	depends on (KVM_GUEST && X86) || (HAVE_ARM_SMCCC_DISCOVERY && ARM_ARCH_TIMER)
-	default y
-	help
-	  This driver adds support for using kvm infrastructure as a PTP
-	  clock. This clock is only useful if you are using KVM guests.
-
-	  To compile this driver as a module, choose M here: the module
-	  will be called ptp_kvm.
-
-config PTP_1588_CLOCK_VMCLOCK
-	tristate "Virtual machine PTP clock"
-	depends on X86_TSC || ARM_ARCH_TIMER
-	depends on PTP_1588_CLOCK && ARCH_SUPPORTS_INT128
-	default PTP_1588_CLOCK_KVM
-	help
-	  This driver adds support for using a virtual precision clock
-	  advertised by the hypervisor. This clock is only useful in virtual
-	  machines where such a device is present.
-
-	  Unlike the KVM virtual PTP clock, the VMCLOCK device offers support
-	  for reliable timekeeping even across live migration. So this driver
-	  is enabled by default whenever the KVM PTP clock is.
-
-	  To compile this driver as a module, choose M here: the module
-	  will be called ptp_vmclock.
-
 config PTP_1588_CLOCK_IDT82P33
 	tristate "IDT 82P33xxx PTP clock"
 	depends on PTP_1588_CLOCK && I2C
@@ -195,18 +171,6 @@ config PTP_1588_CLOCK_MOCK
 	  To compile this driver as a module, choose M here: the module
 	  will be called ptp_mock.
 
-config PTP_1588_CLOCK_VMW
-	tristate "VMware virtual PTP clock"
-	depends on ACPI && HYPERVISOR_GUEST && X86
-	depends on PTP_1588_CLOCK
-	help
-	  This driver adds support for using VMware virtual precision
-	  clock device as a PTP clock. This is only useful in virtual
-	  machines running on VMware virtual infrastructure.
-
-	  To compile this driver as a module, choose M here: the module
-	  will be called ptp_vmw.
-
 config PTP_1588_CLOCK_OCP
 	tristate "OpenCompute TimeCard as PTP clock"
 	depends on PTP_1588_CLOCK
@@ -241,18 +205,6 @@ config PTP_DFL_TOD
 	  To compile this driver as a module, choose M here: the module
 	  will be called ptp_dfl_tod.
 
-config PTP_S390
-	tristate "S390 PTP driver"
-	depends on PTP_1588_CLOCK
-	depends on S390
-	help
-	  This driver adds support for S390 time steering via the PtP
-	  interface. This works by adding a in-kernel clock delta value,
-	  which is always added to time values used in the kernel. The PtP
-	  driver provides the raw clock value without the delta to
-	  userspace. That way userspace programs like chrony could steer
-	  the kernel clock.
-
 config PTP_NETC_V4_TIMER
 	tristate "NXP NETC V4 Timer PTP Driver"
 	depends on PTP_1588_CLOCK
@@ -263,4 +215,6 @@ config PTP_NETC_V4_TIMER
 	  synchronization. It also supports periodic output signal (e.g. PPS)
 	  and external trigger timestamping.
 
+source "drivers/ptp/emulated/Kconfig"
+
 endmenu
diff --git a/drivers/ptp/Makefile b/drivers/ptp/Makefile
index bdc47e284f14..bcea2d3d4efd 100644
--- a/drivers/ptp/Makefile
+++ b/drivers/ptp/Makefile
@@ -1,24 +1,21 @@
 # SPDX-License-Identifier: GPL-2.0
 #
-# Makefile for PTP 1588 clock support.
+# Makefile for PTP clock support.
 #
 
+subdir-ccflags-y += -I$(srctree)/drivers/ptp
+
 ptp-y					:= ptp_clock.o ptp_chardev.o ptp_sysfs.o ptp_vclock.o
-ptp_kvm-$(CONFIG_X86)			:= ptp_kvm_x86.o ptp_kvm_common.o
-ptp_kvm-$(CONFIG_HAVE_ARM_SMCCC)	:= ptp_kvm_arm.o ptp_kvm_common.o
 obj-$(CONFIG_PTP_1588_CLOCK)		+= ptp.o
 obj-$(CONFIG_PTP_1588_CLOCK_DTE)	+= ptp_dte.o
 obj-$(CONFIG_PTP_1588_CLOCK_INES)	+= ptp_ines.o
 obj-$(CONFIG_PTP_1588_CLOCK_PCH)	+= ptp_pch.o
-obj-$(CONFIG_PTP_1588_CLOCK_KVM)	+= ptp_kvm.o
-obj-$(CONFIG_PTP_1588_CLOCK_VMCLOCK)	+= ptp_vmclock.o
 obj-$(CONFIG_PTP_1588_CLOCK_QORIQ)	+= ptp_qoriq.o
 obj-$(CONFIG_PTP_1588_CLOCK_IDTCM)	+= ptp_clockmatrix.o
 obj-$(CONFIG_PTP_1588_CLOCK_FC3W)	+= ptp_fc3.o
 obj-$(CONFIG_PTP_1588_CLOCK_IDT82P33)	+= ptp_idt82p33.o
 obj-$(CONFIG_PTP_1588_CLOCK_MOCK)	+= ptp_mock.o
-obj-$(CONFIG_PTP_1588_CLOCK_VMW)	+= ptp_vmw.o
 obj-$(CONFIG_PTP_1588_CLOCK_OCP)	+= ptp_ocp.o
 obj-$(CONFIG_PTP_DFL_TOD)		+= ptp_dfl_tod.o
-obj-$(CONFIG_PTP_S390)			+= ptp_s390.o
 obj-$(CONFIG_PTP_NETC_V4_TIMER)		+= ptp_netc.o
+obj-$(CONFIG_PTP_1588_CLOCK)		+= emulated/
diff --git a/drivers/ptp/emulated/Kconfig b/drivers/ptp/emulated/Kconfig
new file mode 100644
index 000000000000..3e11f78dfbd8
--- /dev/null
+++ b/drivers/ptp/emulated/Kconfig
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Emulated PTP clock drivers configuration
+#
+
+menu "Emulated PTP clock drivers"
+
+config PTP_1588_CLOCK_KVM
+	tristate "KVM virtual PTP clock"
+	depends on PTP_1588_CLOCK
+	depends on (KVM_GUEST && X86) || (HAVE_ARM_SMCCC_DISCOVERY && ARM_ARCH_TIMER)
+	default y
+	help
+	  This driver adds support for using kvm infrastructure as a PTP
+	  clock. This clock is only useful if you are using KVM guests.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called ptp_kvm.
+
+config PTP_1588_CLOCK_VMCLOCK
+	tristate "Virtual machine PTP clock"
+	depends on X86_TSC || ARM_ARCH_TIMER
+	depends on PTP_1588_CLOCK && ARCH_SUPPORTS_INT128
+	default PTP_1588_CLOCK_KVM
+	help
+	  This driver adds support for using a virtual precision clock
+	  advertised by the hypervisor. This clock is only useful in virtual
+	  machines where such a device is present.
+
+	  Unlike the KVM virtual PTP clock, the VMCLOCK device offers support
+	  for reliable timekeeping even across live migration. So this driver
+	  is enabled by default whenever the KVM PTP clock is.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called ptp_vmclock.
+
+config PTP_1588_CLOCK_VMW
+	tristate "VMware virtual PTP clock"
+	depends on ACPI && HYPERVISOR_GUEST && X86
+	depends on PTP_1588_CLOCK
+	help
+	  This driver adds support for using VMware virtual precision
+	  clock device as a PTP clock. This is only useful in virtual
+	  machines running on VMware virtual infrastructure.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called ptp_vmw.
+
+config PTP_S390
+	tristate "S390 PTP driver"
+	depends on PTP_1588_CLOCK
+	depends on S390
+	help
+	  This driver adds support for S390 time steering via the PtP
+	  interface. This works by adding a in-kernel clock delta value,
+	  which is always added to time values used in the kernel. The PtP
+	  driver provides the raw clock value without the delta to
+	  userspace. That way userspace programs like chrony could steer
+	  the kernel clock.
+
+endmenu
diff --git a/drivers/ptp/emulated/Makefile b/drivers/ptp/emulated/Makefile
new file mode 100644
index 000000000000..577917df3dc9
--- /dev/null
+++ b/drivers/ptp/emulated/Makefile
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for emulated PTP clocks.
+#
+
+ptp_kvm-$(CONFIG_X86)			:= ptp_kvm_x86.o ptp_kvm_common.o
+ptp_kvm-$(CONFIG_HAVE_ARM_SMCCC)	:= ptp_kvm_arm.o ptp_kvm_common.o
+obj-$(CONFIG_PTP_1588_CLOCK_KVM)	+= ptp_kvm.o
+obj-$(CONFIG_PTP_1588_CLOCK_VMCLOCK)	+= ptp_vmclock.o
+obj-$(CONFIG_PTP_1588_CLOCK_VMW)	+= ptp_vmw.o
+obj-$(CONFIG_PTP_S390)			+= ptp_s390.o
diff --git a/drivers/ptp/ptp_kvm_arm.c b/drivers/ptp/emulated/ptp_kvm_arm.c
similarity index 100%
rename from drivers/ptp/ptp_kvm_arm.c
rename to drivers/ptp/emulated/ptp_kvm_arm.c
diff --git a/drivers/ptp/ptp_kvm_common.c b/drivers/ptp/emulated/ptp_kvm_common.c
similarity index 100%
rename from drivers/ptp/ptp_kvm_common.c
rename to drivers/ptp/emulated/ptp_kvm_common.c
diff --git a/drivers/ptp/ptp_kvm_x86.c b/drivers/ptp/emulated/ptp_kvm_x86.c
similarity index 100%
rename from drivers/ptp/ptp_kvm_x86.c
rename to drivers/ptp/emulated/ptp_kvm_x86.c
diff --git a/drivers/ptp/ptp_s390.c b/drivers/ptp/emulated/ptp_s390.c
similarity index 100%
rename from drivers/ptp/ptp_s390.c
rename to drivers/ptp/emulated/ptp_s390.c
diff --git a/drivers/ptp/ptp_vmclock.c b/drivers/ptp/emulated/ptp_vmclock.c
similarity index 100%
rename from drivers/ptp/ptp_vmclock.c
rename to drivers/ptp/emulated/ptp_vmclock.c
diff --git a/drivers/ptp/ptp_vmw.c b/drivers/ptp/emulated/ptp_vmw.c
similarity index 100%
rename from drivers/ptp/ptp_vmw.c
rename to drivers/ptp/emulated/ptp_vmw.c
-- 
2.43.5

[PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split

[Wen Gu]

Update MAINTAINERS to match the new drivers/ptp/ directory layout after
moving emulated/virtual PTP clock drivers into a new subdirectory.

Adjust file patterns and per-driver entries to point to their new
locations, and add a dedicated MAINTAINERS entry for the emulated PTP
clock drivers.

Signed-off-by: Wen Gu <guwen@linux.alibaba.com>
---
 MAINTAINERS | 21 ++++++++++++++++-----
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index cb48c9ad9ddc..2b5464e38238 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18335,6 +18335,7 @@ X:	Documentation/devicetree/bindings/net/can/
 X:	Documentation/devicetree/bindings/net/wireless/
 X:	drivers/net/can/
 X:	drivers/net/wireless/
+X:	drivers/ptp/emulated/
 
 NETWORKING DRIVERS (WIRELESS)
 M:	Johannes Berg <johannes@sipsolutions.net>
@@ -21243,8 +21244,18 @@ F:	Documentation/driver-api/ptp.rst
 F:	drivers/net/phy/dp83640*
 F:	drivers/ptp/*
 F:	include/linux/ptp_cl*
+X:	drivers/ptp/emulated/
 K:	(?:\b|_)ptp(?:\b|_)
 
+PTP EMULATED CLOCK SUPPORT
+M:	David Woodhouse <dwmw2@infradead.org>
+M:	Wen Gu <guwen@linux.alibaba.com>
+M:	Xuan Zhuo <xuanzhuo@linux.alibaba.com>
+L:	linux-kernel@vger.kernel.org
+S:	Maintained
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core
+F:	drivers/ptp/emulated/
+
 PTP MOCKUP CLOCK SUPPORT
 M:	Vladimir Oltean <vladimir.oltean@nxp.com>
 L:	netdev@vger.kernel.org
@@ -21261,10 +21272,10 @@ F:	net/ethtool/phc_vclocks.c
 
 PTP VMCLOCK SUPPORT
 M:	David Woodhouse <dwmw2@infradead.org>
-L:	netdev@vger.kernel.org
+L:	linux-kernel@vger.kernel.org
 S:	Maintained
 F:	Documentation/devicetree/bindings/ptp/amazon,vmclock.yaml
-F:	drivers/ptp/ptp_vmclock.c
+F:	drivers/ptp/emulated/ptp_vmclock.c
 F:	include/uapi/linux/vmclock-abi.h
 
 PTRACE SUPPORT
@@ -23323,7 +23334,7 @@ S390 PTP DRIVER
 M:	Sven Schnelle <svens@linux.ibm.com>
 L:	linux-s390@vger.kernel.org
 S:	Supported
-F:	drivers/ptp/ptp_s390.c
+F:	drivers/ptp/emulated/ptp_s390.c
 
 S390 SCM DRIVER
 M:	Vineeth Vijayan <vneethv@linux.ibm.com>
@@ -28219,9 +28230,9 @@ M:	Nick Shi <nick.shi@broadcom.com>
 R:	Ajay Kaher <ajay.kaher@broadcom.com>
 R:	Alexey Makhalov <alexey.makhalov@broadcom.com>
 R:	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
-L:	netdev@vger.kernel.org
+L:	linux-kernel@vger.kernel.org
 S:	Supported
-F:	drivers/ptp/ptp_vmw.c
+F:	drivers/ptp/emulated/ptp_vmw.c
 
 VMWARE VMCI DRIVER
 M:	Bryan Tan <bryan-bt.tan@broadcom.com>
-- 
2.43.5

Re: [PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split

[Jakub Kicinski]

On Tue,  7 Apr 2026 18:48:02 +0800 Wen Gu wrote:
> +PTP EMULATED CLOCK SUPPORT
> +M:	David Woodhouse <dwmw2@infradead.org>
> +M:	Wen Gu <guwen@linux.alibaba.com>
> +M:	Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> +L:	linux-kernel@vger.kernel.org
> +S:	Maintained
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core

Hi David,

Do you have a tree to route the patches thru? Or do you really have
access to the tip tree?

Re: [PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split

[David Woodhouse]

On 12 April 2026 16:47:04 BST, Jakub Kicinski <kuba@kernel.org> wrote:
>On Tue,  7 Apr 2026 18:48:02 +0800 Wen Gu wrote:
>> +PTP EMULATED CLOCK SUPPORT
>> +M:	David Woodhouse <dwmw2@infradead.org>
>> +M:	Wen Gu <guwen@linux.alibaba.com>
>> +M:	Xuan Zhuo <xuanzhuo@linux.alibaba.com>
>> +L:	linux-kernel@vger.kernel.org
>> +S:	Maintained
>> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core
>
>Hi David,
>
>Do you have a tree to route the patches thru? Or do you really have
>access to the tip tree?

I do not have access to the tip tree. I can make a shared tree on git.infradead.org if the other two maintainers would like to send me a SSH pubkey and preferred username...

Re: [PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split

[Jakub Kicinski]

On Sun, 12 Apr 2026 17:32:22 +0100 David Woodhouse wrote:
> On 12 April 2026 16:47:04 BST, Jakub Kicinski <kuba@kernel.org> wrote:
> >On Tue,  7 Apr 2026 18:48:02 +0800 Wen Gu wrote:  
> >> +PTP EMULATED CLOCK SUPPORT
> >> +M:	David Woodhouse <dwmw2@infradead.org>
> >> +M:	Wen Gu <guwen@linux.alibaba.com>
> >> +M:	Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> >> +L:	linux-kernel@vger.kernel.org
> >> +S:	Maintained
> >> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core  
> >
> >Hi David,
> >
> >Do you have a tree to route the patches thru? Or do you really have
> >access to the tip tree?  
> 
> I do not have access to the tip tree. I can make a shared tree on
> git.infradead.org if the other two maintainers would like to send me
> a SSH pubkey and preferred username...

Honestly I'd love for you to be the only M here, and the other two 
to be reviewers. Xuan Zhuo is currently at v40 trying to upstream 
an Ethernet driver. Some growth needed there to become a subsystem
maintainer IMO.

Re: [PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split

[Wen Gu]

On 2026/4/13 00:53, Jakub Kicinski wrote:
> On Sun, 12 Apr 2026 17:32:22 +0100 David Woodhouse wrote:
>> On 12 April 2026 16:47:04 BST, Jakub Kicinski <kuba@kernel.org> wrote:
>>> On Tue,  7 Apr 2026 18:48:02 +0800 Wen Gu wrote:
>>>> +PTP EMULATED CLOCK SUPPORT
>>>> +M:	David Woodhouse <dwmw2@infradead.org>
>>>> +M:	Wen Gu <guwen@linux.alibaba.com>
>>>> +M:	Xuan Zhuo <xuanzhuo@linux.alibaba.com>
>>>> +L:	linux-kernel@vger.kernel.org
>>>> +S:	Maintained
>>>> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core
>>>
>>> Hi David,
>>>
>>> Do you have a tree to route the patches thru? Or do you really have
>>> access to the tip tree?
>>
>> I do not have access to the tip tree. I can make a shared tree on
>> git.infradead.org if the other two maintainers would like to send me
>> a SSH pubkey and preferred username...
> 
> Honestly I'd love for you to be the only M here, and the other two
> to be reviewers. Xuan Zhuo is currently at v40 trying to upstream
> an Ethernet driver. Some growth needed there to become a subsystem
> maintainer IMO.

Hi Jakub, David,

That works for us. We can act as reviewers.

If David sets up a new tree, I will update the MAINTAINERS entry
accordingly in v3.

Thanks.

Re: [PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split

[Wen Gu]

On 2026/4/13 17:00, Wen Gu wrote:
> 
> 
> On 2026/4/13 00:53, Jakub Kicinski wrote:
>> On Sun, 12 Apr 2026 17:32:22 +0100 David Woodhouse wrote:
>>> On 12 April 2026 16:47:04 BST, Jakub Kicinski <kuba@kernel.org> wrote:
>>>> On Tue,  7 Apr 2026 18:48:02 +0800 Wen Gu wrote:
>>>>> +PTP EMULATED CLOCK SUPPORT
>>>>> +M:    David Woodhouse <dwmw2@infradead.org>
>>>>> +M:    Wen Gu <guwen@linux.alibaba.com>
>>>>> +M:    Xuan Zhuo <xuanzhuo@linux.alibaba.com>
>>>>> +L:    linux-kernel@vger.kernel.org
>>>>> +S:    Maintained
>>>>> +T:    git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core
>>>>
>>>> Hi David,
>>>>
>>>> Do you have a tree to route the patches thru? Or do you really have
>>>> access to the tip tree?
>>>
>>> I do not have access to the tip tree. I can make a shared tree on
>>> git.infradead.org if the other two maintainers would like to send me
>>> a SSH pubkey and preferred username...
>>
>> Honestly I'd love for you to be the only M here, and the other two
>> to be reviewers. Xuan Zhuo is currently at v40 trying to upstream
>> an Ethernet driver. Some growth needed there to become a subsystem
>> maintainer IMO.
> 
> Hi Jakub, David,
> 
> That works for us. We can act as reviewers.
> 
> If David sets up a new tree, I will update the MAINTAINERS entry
> accordingly in v3.

Hi David,

Just checking if there is any update on the maintainer tree
for the emulated PTP drivers.

Thanks.

> 
> Thanks.

Re: [PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 2750 bytes --]

On Mon, 2026-04-13 at 17:00 +0800, Wen Gu wrote:
> 
> On 2026/4/13 00:53, Jakub Kicinski wrote:
> > On Sun, 12 Apr 2026 17:32:22 +0100 David Woodhouse wrote:
> > > On 12 April 2026 16:47:04 BST, Jakub Kicinski <kuba@kernel.org> wrote:
> > > > On Tue,  7 Apr 2026 18:48:02 +0800 Wen Gu wrote:
> > > > > +PTP EMULATED CLOCK SUPPORT
> > > > > +M:	David Woodhouse <dwmw2@infradead.org>
> > > > > +M:	Wen Gu <guwen@linux.alibaba.com>
> > > > > +M:	Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > > > > +L:	linux-kernel@vger.kernel.org
> > > > > +S:	Maintained
> > > > > +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core
> > > > 
> > > > Hi David,
> > > > 
> > > > Do you have a tree to route the patches thru? Or do you really have
> > > > access to the tip tree?
> > > 
> > > I do not have access to the tip tree. I can make a shared tree on
> > > git.infradead.org if the other two maintainers would like to send me
> > > a SSH pubkey and preferred username...
> > 
> > Honestly I'd love for you to be the only M here, and the other two
> > to be reviewers. Xuan Zhuo is currently at v40 trying to upstream
> > an Ethernet driver. Some growth needed there to become a subsystem
> > maintainer IMO.
> 
> Hi Jakub, David,
> 
> That works for us. We can act as reviewers.
> 
> If David sets up a new tree, I will update the MAINTAINERS entry
> accordingly in v3.

Apologies for the delay. I have set up

https://git.infradead.org/?p=linux-ptp.git
git://git.infradead.org/linux-ptp.git

But I'm not keen on using it without Richard's explicit approval and a
clear understanding of who owns what, *and* the taxonomy we use...

I'm not entirely keen on 'emulated' as the directory name. I don't want
to get too bogged down in bikeshedding, and I know we've done some
already, but I think 'virt' is a better fit? Although when I get my
hands on one of those PTM-capable TimeCards, vmclock won't *just* be
virt... :)

I'm not sure I agree that the drivers being left behind in drivers/ptp
are "IEEE1588 / network-oriented clock drivers" as the commit message
of patch 1 suggests, either. The only one that goes anywhere *near* a
network is ptp_ines.c which has a mii_timestamper interface.

Apart from that they are *all* just PHC clock drivers, aren't they? The
actual network ones live in drivers/net.

So maybe the better answer is to have a more conventional core/drivers
split? Except maybe for ptp_ines is there anything that *network*
maintainers care about, other than the core?

If we do that, add an X: line to exclude the drivers subdir from the
network section in MAINTAINERS, and leave all of drivers/ptp owned by
Richard as it is... do we *need* a new tree? 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split

[Richard Cochran]

On Thu, May 28, 2026 at 06:06:32PM +0100, David Woodhouse wrote:

> Apologies for the delay. I have set up
> 
> https://git.infradead.org/?p=linux-ptp.git
> git://git.infradead.org/linux-ptp.git
> 
> But I'm not keen on using it without Richard's explicit approval and a
> clear understanding of who owns what, *and* the taxonomy we use...

The name "linux-ptp" is very close to "linuxptp" which is the user
space PTP stack.  So it is a bit confusing.

Thanks,
Richard

Re: [PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1159 bytes --]

On Sun, 2026-05-31 at 17:20 -0700, Richard Cochran wrote:
> On Thu, May 28, 2026 at 06:06:32PM +0100, David Woodhouse wrote:
> 
> > Apologies for the delay. I have set up
> > 
> > https://git.infradead.org/?p=linux-ptp.git
> > git://git.infradead.org/linux-ptp.git
> > 
> > But I'm not keen on using it without Richard's explicit approval and a
> > clear understanding of who owns what, *and* the taxonomy we use...
> 
> The name "linux-ptp" is very close to "linuxptp" which is the user
> space PTP stack.  So it is a bit confusing.

The *naming* was the least of the concerns I expressed :)

Before we bikeshed that too hard, we should understand what it would
contain.

If we move all the plain non-network PHC drivers (which, as noted, is
basically *all* of them) into a drivers/ subdirectory, then perhaps we
call it linux-ptp-drivers.git?

I think that addresses Jakub's original complaint which brought us
here, doesn't it?

Although I would quite like to carry things like Arthur's new ioctls,
once they have your blessing. Those will go on top of Thomas's
ktime_get_snapshot series, once that has a stable commit ID. 


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split

[Richard Cochran]

On Mon, Jun 01, 2026 at 08:03:26AM +0100, David Woodhouse wrote:
> If we move all the plain non-network PHC drivers (which, as noted, is
> basically *all* of them) into a drivers/ subdirectory, then perhaps we

Sorry, just catching up here, so the idea is to have

 linux/drivers/ptp/drivers  ?

Thanks,
Richard

Re: [PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]

On Mon, 2026-06-01 at 08:20 -0700, Richard Cochran wrote:
> On Mon, Jun 01, 2026 at 08:03:26AM +0100, David Woodhouse wrote:
> > If we move all the plain non-network PHC drivers (which, as noted,
> > is
> > basically *all* of them) into a drivers/ subdirectory, then perhaps
> > we
> 
> Sorry, just catching up here, so the idea is to have
> 
>  linux/drivers/ptp/drivers  ?

That is my current suggestion.

It stems from Jakub's response in
https://lore.kernel.org/all/20250815113814.5e135318@kernel.org/ that "I
really wish someone stepped up and created a separate subsystem for all
these cloud / vm clocks. They have nothing to do with PTP."

There was some further bikeshedding in
https://lore.kernel.org/netdev/0afe19db-9c7f-4228-9fc2-f7b34c4bc227@linux.alibaba.com/
around how to split 'emulated' from other hardware drivers, but I don't
much like that taxonomy. Some of these "virtual" clocks could just as
easily exist in hardware with PTM too.

My observation is that with the sole exception of ptp_inet.c, *all* of
the actual PHC drivers that live in drivers/ptp instead of drivers/net
are "pure clock" drivers, so perhaps we split those all out into
drivers/ptp/drivers/ and exclude them from the netdev maintenance?

I'm reluctantly prepared to host and help maintain a drivers tree if
it's necessary, but equally as happy to let you own it. 



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split

[Jakub Kicinski]

On Mon, 01 Jun 2026 17:53:49 +0100 David Woodhouse wrote:
> On Mon, 2026-06-01 at 08:20 -0700, Richard Cochran wrote:
> > On Mon, Jun 01, 2026 at 08:03:26AM +0100, David Woodhouse wrote:  
> > > If we move all the plain non-network PHC drivers (which, as noted,
> > > is
> > > basically *all* of them) into a drivers/ subdirectory, then perhaps
> > > we  
> > 
> > Sorry, just catching up here, so the idea is to have
> > 
> >  linux/drivers/ptp/drivers  ?  
> 
> That is my current suggestion.
> 
> It stems from Jakub's response in
> https://lore.kernel.org/all/20250815113814.5e135318@kernel.org/ that "I
> really wish someone stepped up and created a separate subsystem for all
> these cloud / vm clocks. They have nothing to do with PTP."
> 
> There was some further bikeshedding in
> https://lore.kernel.org/netdev/0afe19db-9c7f-4228-9fc2-f7b34c4bc227@linux.alibaba.com/
> around how to split 'emulated' from other hardware drivers, but I don't
> much like that taxonomy. Some of these "virtual" clocks could just as
> easily exist in hardware with PTM too.

Not sure I fully understand what you mean. Practically the distinction
is very clear - the virt devices are implemented by a hypervisor and/or
IPU which may have some HW gadgets and PTM support but beyond that are
software-defined. We don't need help maintaining drivers for
fixed-ASIC (?) clocks, atomic clocks etc. Those are usually time
counter + misc. They are not "devices" which know the wall clock time
better than the host :\

IOW the "does it have a NIC" is not a great distinction.
A better oneliner would be "does it purport to know real time better 
than the host"

> My observation is that with the sole exception of ptp_inet.c, *all* of
> the actual PHC drivers that live in drivers/ptp instead of drivers/net
> are "pure clock" drivers, so perhaps we split those all out into
> drivers/ptp/drivers/ and exclude them from the netdev maintenance?
> 
> I'm reluctantly prepared to host and help maintain a drivers tree if
> it's necessary, but equally as happy to let you own it. 

No strong feelings here, but atomic clocks will start spilling into
DPLL and SyncE pretty quickly.

Re: [PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split

[Richard Cochran]

Sorry for replying to David here via Jakub's message.  Somehow my
brilliant Gmail doesn't have David's reply...

On Mon, Jun 01, 2026 at 06:52:26PM -0700, Jakub Kicinski wrote:
> On Mon, 01 Jun 2026 17:53:49 +0100 David Woodhouse wrote:
> > On Mon, 2026-06-01 at 08:20 -0700, Richard Cochran wrote:
> > > Sorry, just catching up here, so the idea is to have
> > > 
> > >  linux/drivers/ptp/drivers  ?  
> > 
> > That is my current suggestion.

drivers/../drivers seems a bit silly to me

> > It stems from Jakub's response in
> > https://lore.kernel.org/all/20250815113814.5e135318@kernel.org/ that "I
> > really wish someone stepped up and created a separate subsystem for all
> > these cloud / vm clocks. They have nothing to do with PTP."
> > 
> > There was some further bikeshedding in
> > https://lore.kernel.org/netdev/0afe19db-9c7f-4228-9fc2-f7b34c4bc227@linux.alibaba.com/

The idea of categorizing core, NIC-related, vm, and stand alone clock
devices makes some sense to me.

> > around how to split 'emulated' from other hardware drivers, but I don't
> > much like that taxonomy. Some of these "virtual" clocks could just as
> > easily exist in hardware with PTM too.

So the whole in-kernel API in ptp_clock_kernel.h with ptp_clock_info,
etc, was poorly named (by me) back around Linux 3.0.  After all, the
abbreviation, "PTP", stands for a network protocol.  At the time, Alan
Cox pointed that out and complained, but somehow the code got merged
anyhow.

The term PHC is a better one, since PTP Hardware Clock means clock
device whose purpose is to support network time keeping together with
a NIC.

> > My observation is that with the sole exception of ptp_inet.c, *all* of
> > the actual PHC drivers that live in drivers/ptp instead of drivers/net
> > are "pure clock" drivers,

No, that is not quite right.  The clockmatrix, idt82p33, ines, and
qoriq drivers wouldn't be very useful without an attached NIC.

> > so perhaps we split those all out into
> > drivers/ptp/drivers/ and exclude them from the netdev maintenance?

Originally the idea was that the rate of patches would be low enough
that netdev would be the place to post and review them, and that no
separate tree or mailing list were needed. 

Even though the "PTP" naming was an unfortunate choice way back when,
still I'm not a big fan of moving stuff around "just because".

But moving forward, I would suggest starting a new area for pure
hardware clock devices.  

   "Clock Devices" ?
   linux/drivers/cd

Too short!

   "Time Keeping Devices" ?
   linux/drivers/tkd

Confuses core time keeping!

   "Advanced Clock Devices" ?
   linux/drivers/acd

Let's come up with a fitting name.

Still, I don't understand why these new (non-network related ) device
drivers can't be implemented in their own class using posix_clock_register()
etc.

Any of the useful bits (like sysfs interfaces) can be refactored out
of ptp_clock.c and shared as a common layer.

Thanks,
Richard

Re: [PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 6109 bytes --]

On Mon, 2026-06-01 at 21:20 -0700, Richard Cochran wrote:
> 
> Sorry for replying to David here via Jakub's message.  Somehow my
> brilliant Gmail doesn't have David's reply...

Yeah, Gmail. Here's a nickel, kid... :)

> On Mon, Jun 01, 2026 at 06:52:26PM -0700, Jakub Kicinski wrote:
> > On Mon, 01 Jun 2026 17:53:49 +0100 David Woodhouse wrote:
> > > On Mon, 2026-06-01 at 08:20 -0700, Richard Cochran wrote:
> > > > Sorry, just catching up here, so the idea is to have
> > > > 
> > > >  linux/drivers/ptp/drivers  ?  
> > > 
> > > That is my current suggestion.
> 
> drivers/../drivers seems a bit silly to me

It wouldn't be the first, but yeah — more conventional would be to have
the core elsewhere and the drivers under linux/drivers/. 

That maybe involves moving the PTP core to kernel/time/ptp[/*] while
leaving the drivers where they are?

But first we have to know the problem we're trying to solve, and Jakub
has just revised my understanding of what he was originally asking for.

> > > It stems from Jakub's response in
> > > https://lore.kernel.org/all/20250815113814.5e135318@kernel.org/ that "I
> > > really wish someone stepped up and created a separate subsystem for all
> > > these cloud / vm clocks. They have nothing to do with PTP."
> > > 
> > > There was some further bikeshedding in
> > > https://lore.kernel.org/netdev/0afe19db-9c7f-4228-9fc2-f7b34c4bc227@linux.alibaba.com/
> 
> The idea of categorizing core, NIC-related, vm, and stand alone clock
> devices makes some sense to me.
> 
> > > around how to split 'emulated' from other hardware drivers, but I don't
> > > much like that taxonomy. Some of these "virtual" clocks could just as
> > > easily exist in hardware with PTM too.
> 
> So the whole in-kernel API in ptp_clock_kernel.h with ptp_clock_info,
> etc, was poorly named (by me) back around Linux 3.0.  After all, the
> abbreviation, "PTP", stands for a network protocol.  At the time, Alan
> Cox pointed that out and complained, but somehow the code got merged
> anyhow.
> 
> The term PHC is a better one, since PTP Hardware Clock means clock
> device whose purpose is to support network time keeping together with
> a NIC.
> 
> > > My observation is that with the sole exception of ptp_inet.c, *all* of
> > > the actual PHC drivers that live in drivers/ptp instead of drivers/net
> > > are "pure clock" drivers,
> 
> No, that is not quite right.  The clockmatrix, idt82p33, ines, and
> qoriq drivers wouldn't be very useful without an attached NIC.

Ah, OK. Moderately confused because ines is the only one where I see
any evidence of hwtstamp support, and the rest just seem to provide a
PHC, but I'll take your word for it.

> > > so perhaps we split those all out into
> > > drivers/ptp/drivers/ and exclude them from the netdev maintenance?
> 
> Originally the idea was that the rate of patches would be low enough
> that netdev would be the place to post and review them, and that no
> separate tree or mailing list were needed. 

I think that assumption about the rate of patches should still be true.
If I end up owning a tree for the 'virt' drivers, I'd mostly be
answering "no, use VMClock instead". There's a reason I found a home
for that as a vendor-agnostic specification¹ and built the QEMU and
guest kernel support before even pushing it out at $DAYJOB.

¹ https://uapi-group.org/specifications/specs/vmclock/

> Even though the "PTP" naming was an unfortunate choice way back when,
> still I'm not a big fan of moving stuff around "just because".
> 
> But moving forward, I would suggest starting a new area for pure
> hardware clock devices.  

I think that ties relatively well to Jakub's "does it purport to know
real time better than the host" criterion?

Although... ENA *both* purports to know real time better than the host
*and* does packet timestamping, and it looks like GVE is attempting to
do the same?

>    "Clock Devices" ?
>    linux/drivers/cd
> 
> Too short!
> 
>    "Time Keeping Devices" ?
>    linux/drivers/tkd
> 
> Confuses core time keeping!

That isn't necessarily a bad thing... (qv)

>    "Advanced Clock Devices" ?
>    linux/drivers/acd
> 
> Let's come up with a fitting name.
> 
> Still, I don't understand why these new (non-network related ) device
> drivers can't be implemented in their own class using
> posix_clock_register()
> etc.
> 
> Any of the useful bits (like sysfs interfaces) can be refactored out
> of ptp_clock.c and shared as a common layer.

The key is that userspace wants to get snapshots of the reference clock
either precisely synchronized with the system clock where possible, or
sandwiched as closely together as possible with ABA readings of the
system, reference, system clock.

Those *are* the PTP_SYS_OFFSET* ioctls, which tools like chrony already
support with 'refclock PHC /dev/ptp…'.

I'm not sure how factoring those out into separate POSIX AUX clocks
would help? I think they do want to present as /dev/ptp*.

There is some extra stuff we want to do for "Precision RTCs" or
whatever we're going to call them. They might actually have a known TAI
offset, they might convey leap second indications, we might want to set
the kernel's CLOCK_REALTIME from them at boot. And in the case of
VMClock, I'm working on being able to clamp the kernel's timekeeping to
it directly².

So maybe what we want is linux/drivers/phc, to host those read-only
devices which know real time. They can provide a simplified
implementation; maybe *only* a function like vmclock_get_crosststamp(),
which is just called in various different permutations by the various
different PTP methods.

The core linux/drivers/phc code would then handle the interface to the
kernel's core timekeeping *and* wrap them to register a PTP device that
existing userspace can understand. And deal with the kvmclock/TSC
awfulness where needed.

How does that sound? 


² https://lore.kernel.org/all/20260520135207.37826-9-dwmw2@infradead.org/






[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split

[Wen Gu]

On 2026/6/2 00:53, David Woodhouse wrote:
> On Mon, 2026-06-01 at 08:20 -0700, Richard Cochran wrote:
>> On Mon, Jun 01, 2026 at 08:03:26AM +0100, David Woodhouse wrote:
>>> If we move all the plain non-network PHC drivers (which, as noted,
>>> is
>>> basically *all* of them) into a drivers/ subdirectory, then perhaps
>>> we
>>
>> Sorry, just catching up here, so the idea is to have
>>
>>   linux/drivers/ptp/drivers  ?
> 
> That is my current suggestion.
> 
> It stems from Jakub's response in
> https://lore.kernel.org/all/20250815113814.5e135318@kernel.org/ that "I
> really wish someone stepped up and created a separate subsystem for all
> these cloud / vm clocks. They have nothing to do with PTP."
> 
> There was some further bikeshedding in
> https://lore.kernel.org/netdev/0afe19db-9c7f-4228-9fc2-f7b34c4bc227@linux.alibaba.com/
> around how to split 'emulated' from other hardware drivers, but I don't
> much like that taxonomy. Some of these "virtual" clocks could just as
> easily exist in hardware with PTM too.
> 
> My observation is that with the sole exception of ptp_inet.c, *all* of
> the actual PHC drivers that live in drivers/ptp instead of drivers/net
> are "pure clock" drivers, so perhaps we split those all out into
> drivers/ptp/drivers/ and exclude them from the netdev maintenance?
> 

I think we don't need to split out all of them. The motivation was
to find an appropriate home for the PHC drivers that are read-only
and not disciplined by the host (ptp_vmw, ptp_vmclock, ptp_s390 and
the newly proposed ptp_cipu); they have little to do with networking.
The others are adjustable and tied to the network synchronization
stack (e.g. ptp4l); netdev is the right home for them.

My view is similar to Jakub's: the dividing line is whether the clock
provides authoritative time to the host and does not need to be
disciplined by it.

   Class A -- stays under netdev:
   - has its own physical counter/oscillator;
   - is adjustable (adjfine/adjtime/settime).

   Class B -- to be split out:
   - its time is maintained by an external source (hypervisor, DPU/IPU,
     or platform/arch);
   - the host side can only read it, not adjust it.

I will also adjust the relevant wording in the patch set accordingly,
dropping terms such as "non-NIC", "networking" and "IEEE 1588".

On the category name: the drivers we are splitting out only
provide time readout and do not support host discipline -- they behave
like a partial PHC. From that angle I think 'emulated' is defensible,
but I am also open to a better alternative.

> I'm reluctantly prepared to host and help maintain a drivers tree if
> it's necessary, but equally as happy to let you own it.
> 
> 

Thanks.