On Fri, Jun 26, 2026 at 12:49:41PM +0200, Thomas Gleixner wrote: > 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.
Ack. However the kdocs call it 'CLOCK_MONOTONIC_RAW'. Can we clean this up? > 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 for the clarifications. Thomas
