On Fri, 2026-05-15 at 16:40 +0000, Arthur Kiyanovski wrote:
>
> + * struct ptp_clock_attributes - describes additional data for a PTP clock
> + * timestamp
> + *
> + * @error_bound: The maximum possible error (in nanoseconds) associated
> with
> + * the reported timestamp, this value quantifies the
> inaccuracy
> + * of the clock at the time of reading. A value of UINT_MAX
> + * indicates that the error bound is unknown or unavailable.
> + * @timescale: Clock timescale for timestamp interpretation
> + * (enum ptp_clock_timescale).
> + * @status: Qualitative synchronization status of the clock
> + * (enum ptp_clock_status).
> + * @counter_id: Identifies the hardware counter used to produce
> + * counter_value (enum ptp_counter_id).
> + * PTP_COUNTER_UNKNOWN (0) means no counter is available.
> + * @rsv: Reserved for future use, should be set to zero.
> + * @counter_value: Raw hardware counter value (e.g. TSC ticks) captured at
> + * the time of the PHC timestamp reading. Zero with
> + * counter_id == PTP_COUNTER_UNKNOWN means not available.
> + */
> +struct ptp_clock_attributes {
> + __u32 error_bound;
> + __u8 timescale;
> + __u8 status;
> + __u8 counter_id;
> + __u8 rsv;
> + __u64 counter_value;
> +};
> +
Thomas points out that the counter_id and counter_value don't really
belong there in the clock attributes.
Better to use a system_counterval_t which goes along with each
*timestamp*.
In fact, I think it needs to be in the struct ptp_system_timestamp as
it strictly goes along with each timestamp?
And the ptp_read_system_p{re,ost}ts() helpers need to use the
ktime_get_snapshot_id() that Thomas posted at the end of
https://lore.kernel.org/all/87tss0vdrj.ffs@tglx/
I think we need to make it clear that unless the hardware device
actually does *have* a synchronized counter value (through PTM or by
being a virt device that works that way), it *shouldn't* provide a
counter value at all in the device reading.
smime.p7s
Description: S/MIME cryptographic signature
