Re: [PATCH v4 net-next 0/7] ptp: Add PHC timestamp quality attributes

[David Woodhouse <dwmw2@infradead.org>]

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

On Sun, 2026-07-26 at 18:41 -0700, Richard Cochran wrote:
> On Tue, Jul 14, 2026 at 02:03:01AM +0000, Arthur Kiyanovski wrote:
> > This series adds quality attributes to PTP Hardware Clock (PHC)
> > timestamps, allowing userspace to obtain error bound, clock status,
> > timescale, and system counter values alongside timestamps in a
> > single
> > call.
> > 
> > Motivation
> > ----------
> > The existing PTP APIs return timestamps without any indication of
> > their quality. Applications that need clock accuracy and
> > synchronization status commonly rely on external tools such as
> > ptp4l, which implement synchronization logic and can export their
> > measurement of clock accuracy.
> 
> Yes, and what is wrong with that?  Nothing, AFAICT

Sure, there's nothing wrong with that when it's userspace which is
actually doing the discipline of the clock.

This is for the cases where the device itself is responsible for the
discipline, and the driver is merely transporting the clock status.

> ? For managed PHC devices — such as
> > the ENA network adapter, whose clock is synchronized by the device
> > without userspace involvement — these tools are not available, and
> > the existing APIs lack a way to report quality metrics to consumers
> > of time.
> 
> So make some user space tool that advertises your device's qualities.

I suppose we could invent different device-specific ways for each of
the drivers to expose the same information? But let's not.

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