On Fri, Jun 26 2026 at 10:48, Thomas Weißschuh wrote:
> On Tue, May 26, 2026 at 07:14:13PM +0200, Thomas Gleixner wrote:
> (...)
>
>> static inline void tk_update_aux_offs(struct timekeeper *tk, ktime_t offs)
>> @@ -1218,6 +1223,12 @@ bool ktime_get_snapshot_id(struct system
>> tkd = &tk_core;
>> offs = &tk_core.timekeeper.offs_boot;
>> break;
>> + case CLOCK_AUX ... CLOCK_AUX_LAST:
>> + tkd = aux_get_tk_data(clock_id);
>> + if (!tkd)
>> + return false;
>> + offs = &tkd->timekeeper.offs_aux;
>> + break;
>
> 'tkd' is also used to compute 'monoraw'. However 'tkr_raw' and 'tkr_mono'
> are the same for auxilary clocks, so this will compute a wrong 'monoraw'.
AUX clocks are independent in the first place and the MONORAW part is
the "MONORAW" related to the AUX clock itself.
> Instead 'monoraw' should be computed based on 'tk_core'.
> Which then also requires the sequence locking of 'tk_core'.
No. From a PTP and steering point of view you want the "raw" value which
is related to the AUX clock itself and not the global one.
The global MONORAW and the AUX clock MONORAW are related obviously as
they share the same conversion factors.
MONORAW(AUX$N) = MONORAW(GLOBAL) + OFFSET(AUX$N)
We don't have that information anywhere right now and we might want to
expose it to allow user space a proper correlation, but that's an
orthogonal problem.
>From a PTP/steering point of view the code is correct as is.
Thanks,
tglx
