On 15.09.23 15:30, Thomas Gleixner wrote:
> Peter!
>
> On Fri, Aug 18 2023 at 03:12, Peter Hilber wrote:
>> --- a/arch/x86/kernel/tsc.c
>> +++ b/arch/x86/kernel/tsc.c
>> @@ -1313,7 +1313,7 @@ struct system_counterval_t convert_art_to_tsc(u64 art)
>> res += tmp + art_to_tsc_offset;
>>
>> return (struct system_counterval_t) {
>> - .cs = have_art ? &clocksource_tsc : NULL,
>> + .cs_id = have_art ? CSID_TSC : CSID_GENERIC,
>> .cycles = res
>
> Can you please change all of this so that:
>
> patch 1: Adds cs_id to struct system_counterval_t
> patch 2-4: Add the clocksource ID and set the cs_id field
> patch 5: Switches the core to evaluate cs_id
> patch 6: Remove the cs field from system_counterval_t
OK. For 2-4, I assume split x86/tsc, x86/kvm, drivers/ptp (which
also handles the CSID_ARM_ARCH_COUNTER case).
>> --- a/include/linux/timekeeping.h
>> +++ b/include/linux/timekeeping.h
>> @@ -270,12 +270,12 @@ struct system_device_crosststamp {
>> * struct system_counterval_t - system counter value with the pointer to the
>> * corresponding clocksource
>> * @cycles: System counter value
>> - * @cs: Clocksource corresponding to system counter value. Used by
>> + * @cs_id: Clocksource corresponding to system counter value. Used by
>> * timekeeping code to verify comparibility of two cycle values
>
> That comment is inaccurate. It's not longer the clocksource itself. It's
> the ID which is used for validation.
I will change the comment to refer to "Clocksource ID".
Thanks for the advice!
Peter
