[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ttqp5wjs.ffs@tglx>
Date: Tue, 17 Oct 2023 13:16:07 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: lakshmi.sowjanya.d@...el.com, jstultz@...gle.com,
giometti@...eenne.com, corbet@....net, linux-kernel@...r.kernel.org
Cc: x86@...nel.org, linux-doc@...r.kernel.org,
andriy.shevchenko@...ux.intel.com, eddie.dong@...el.com,
christopher.s.hall@...el.com, pandith.n@...el.com,
mallikarjunappa.sangannavar@...el.com, thejesh.reddy.t.r@...el.com,
lakshmi.sowjanya.d@...el.com
Subject: Re: [PATCH v1 3/6] x86/tsc: Check if the current clock source is
related to ART(Always Running Timer)
On Tue, Oct 17 2023 at 10:54, lakshmi.sowjanya.d@...el.com wrote:
> From: Lakshmi Sowjanya D <lakshmi.sowjanya.d@...el.com>
>
> Add interface 'is_current_clocksource_art_related()' in tsc.c to check
> if the current clock source is ART related.
> Add helper function 'is_current_clocksource(clock)' in timekeeping.c to
> check if the provided clock matches the current clock source.
Again. That's the WHAT not the WHY.
Also the Subject suggests that a check is added at some random place,
but that's not what the patch does.
> +/*
> + * Checks if the current clocksource is ART related clocksource
> + *
> + * Return: 1 on success, 0 on failure.
> + */
> +bool is_current_clocksource_art_related(void)
> +{
> + return is_current_clocksource(art_related_clocksource);
> +}
> +EXPORT_SYMBOL_GPL(is_current_clocksource_art_related);
> +bool is_current_clocksource(struct clocksource *clock)
> +{
> + struct tk_read_base *tkr = &tk_core.timekeeper.tkr_mono;
> + return clock == READ_ONCE(tkr->clock);
> +}
> +EXPORT_SYMBOL_GPL(is_current_clocksource);
Aside of the horrible function names (new global functions want
$NAMESPACE_* convention) this really starts to become hilarious.
Two exported helpers which are completely unexplained. That smells badly
of broken data representations.
But let me see what this is used for.
Thanks,
tglx
Powered by blists - more mailing lists