Re: [patch 09/24] timekeeping: Add CLOCK_AUX support for ktime_get_snapshot_id()

[Thomas Gleixner]

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.