On Tue, 2026-05-19 at 16:33 -0700, Jakub Kicinski wrote: > On Tue, 19 May 2026 18:17:16 +0000 Arthur Kiyanovski wrote: > > On 2026-05-18 18:26:46-07:00, Jakub Kicinski wrote: > > > On Fri, 15 May 2026 16:40:20 +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 raw counter values alongside timestamps in a single > > > > call. > > > > > > How does this proposal relate to: > > > > > > https://lore.kernel.org/all/[email protected]/ > > > > > > ? > > The two series are independent and complementary. This patchset adds a > > generic PTP subsystem interface for reporting quality attributes (error > > bounds, clock status) alongside PHC timestamps — it's a userspace-facing > > API extension. The RFC is about kernel-internal feed-forward clock > > discipline, letting the timekeeping subsystem lock directly to a vmclock > > reference. > > > > Both touch ptp_vmclock.c but in different code paths: this series adds a > > gettimexattrs64 callback for PTP chardev ioctls, the RFC adds > > timekeeping_set_reference() for kernel-internal clock steering. No > > functional dependency or overlap. > > I suspect David will agree, but it'd nonetheless be good to see his > review tag on these patches.
Yeah, I'm generally happy (I'd done a round of review internally, but it's considered bad form to include my Reviewed-by: unless I give it publicly on the list). My series is basically orthogonal, as Arthur says. What I do want to check, though, is the intersection between this one and https://lore.kernel.org/all/[email protected]/ which also appears to be giving the sandwiched timestamps as raw cycle counts — which is what I'd asked Arthur to expose to userspace.
smime.p7s
Description: S/MIME cryptographic signature
