netdev - Re: PTP framework for non-IEEE 1588 clocks

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-next>] [day] [month] [year] [list]

Message-ID: <vmwwnl3zv26lmmuqp2vqltg2fudalpc5jrw7k6ifg6l5cwlk3j@i7jm62zcsl67>
Date: Mon, 19 Jan 2026 14:58:47 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Andrew Lunn <andrew+netdev@...n.ch>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Cc: netdev@...r.kernel.org, Wen Gu <guwen@...ux.alibaba.com>
Subject: Re: PTP framework for non-IEEE 1588 clocks

Hi Jakub et al.,

This is a follow-up of the recent discussion [1] around using PTP framework for
device clocks which doesn't the follow IEEE 1588 standard, but just provide the
high precision clock source to the host machine for time synchronization.

Jakub raised the concern on exposing these kind of high precision clocks as PTP
clocks during the referenced patch review and also during [2]. I agree that the
concern is technically valid as these clock are not following the IEEE 1588
standard.

I then looked into the existing PTP drivers and noticed that many drivers like
ptp_kvm, ptp_vmclock, and ptp_s390 fall into the above category. But that could
be because no one cared about them being non-conformant so far. So I'm not using
them as an excuse.

Then I looked into creating a new framework which just registers as a simple
posix clock and supporting posix_clock_operations::clock_getres operation as a
start. However, it feels like it would be a stripped down version of PTP
framework, with a new class, and chardev interface.

Creating such new interfaces means, we should also teach the tools like phc2sys
(for -a option) to learn about this new interface/class.

So my question is, is it really worth the effort to create a new framework for
providing a subset of the existing framework's functionality? Even if such
framework gets introduced, should the existing non-IEEE 1588 drivers be
converted? I personally think it is not a good idea since that will break the
userspace tooling, but leaving them as is could also induce confusion.

I'm looking for other suggestions as well, thanks!

- Mani

[1] https://lore.kernel.org/mhi/20250821180247.29d0f4b3@kernel.org/
[2] https://lore.kernel.org/all/20250815113814.5e135318@kernel.org/

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