Messages in this thread | | | Date | Fri, 15 Sep 2023 16:29:26 +0200 | From | Peter Hilber <> | Subject | Re: [RFC PATCH 4/4] treewide: Use clocksource id for struct system_counterval_t |
| |
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
| |