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

Message-ID: <2r55e3ohmijdubdwrwagmvfwhehocdqwmmbpmwz4owxpxtenwf@fgzrm3pvve4w>
Date: Mon, 19 Jan 2026 19:55:19 +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

On Mon, Jan 19, 2026 at 02:59:02PM +0530, Manivannan Sadhasivam wrote:
> 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!
> 

Just found this thread which discusses the same problem:
https://lore.kernel.org/all/0afe19db-9c7f-4228-9fc2-f7b34c4bc227@linux.alibaba.com/

I'll chime into it and this thread can be ignored, thanks!

- Mani

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