netdev - Re: [RFC 0/3] ptp: Add esterror support

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

Message-ID: <ed2519db-b3f8-4ab8-9c89-720633100490@machnikowski.net>
Date: Fri, 16 Aug 2024 00:06:51 +0200
From: Maciek Machnikowski <maciek@...hnikowski.net>
To: Richard Cochran <richardcochran@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, Vadim Fedorenko
 <vadim.fedorenko@...ux.dev>, netdev@...r.kernel.org,
 jacob.e.keller@...el.com, darinzon@...zon.com, kuba@...nel.org
Subject: Re: [RFC 0/3] ptp: Add esterror support



On 15/08/2024 23:08, Richard Cochran wrote:
> On Thu, Aug 15, 2024 at 05:00:24PM +0200, Maciek Machnikowski wrote:
> 
>> Think about a Time Card
>> (https://opencomputeproject.github.io/Time-Appliance-Project/docs/time-card/introduction).
> 
> No, I won't think about that!
> 
> You need to present the technical details in the form of patches.
> 
> Hand-wavey hints don't cut it.
> 
> Thanks,
> Richard

This implementation addresses 3 use cases:

1. Autonomous devices that synchronize themselves to some external
sources (GNSS, NTP, dedicated time sync networks) and have the ability
to return the estimated error from the HW or FW loop to users

2. Multi function devices that may have a single isolated function
synchronizing the device clock (by means of PTP, or PPS or any other)
and letting other functions access the uncertainty information

3. Create a common interface to read the uncertainty from a device
(currently you can use PMC for PTP, but there is no way of receiving
that information from ts2phc)

#1 and #2 requires an interface to the driver to retrieve the error from
a device
#2 requires an interface to adjust the esterror and push it to the device
#3 can be terminated locally in the ptp class driver using the same
principle as the presented ptp_mock implementation, or something more
sophisticated

Also this is an RFC to help align work on this functionality across
different devices ] and validate if that's the right direction. If it is
- there will be a patch series with real drivers returning uncertainty
information using that interface. If it's not - I'd like to understand
what should I improve in the interface.

HTH
Maciek