On Mon, Jun 29 2026 at 05:55, Thomas Weißschuh wrote: > On Fri, Jun 26, 2026 at 05:17:52PM +0200, Thomas Gleixner wrote: >> On Fri, Jun 26 2026 at 13:03, Thomas Weißschuh wrote: >> > 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? >> >> Yes. Something like the below? > > Looks good, thanks. > The corresponding structure definitions are a also affected, though.
True.
