From: Randolph Sapp <rs@ti.com>
To: <rs@ti.com>, <mturquette@baylibre.com>, <sboyd@kernel.org>
Cc: <linux-clk@vger.kernel.org>, <mwalle@kernel.org>
Subject: Re: [PATCH] clk: do not trust cached rates for disabled clocks
Date: Tue, 7 Oct 2025 18:58:13 -0500 [thread overview]
Message-ID: <DDCHX9627F8N.KWJDFIS4TO5O@ti.com> (raw)
In-Reply-To: <20251003222917.706646-2-rs@ti.com>
On Fri Oct 3, 2025 at 5:29 PM CDT, rs wrote:
> From: Randolph Sapp <rs@ti.com>
>
> Recalculate the clock rate for unprepared clocks. This cached value can
> vary depending on the clocking architecture. On platforms with clocks
> that have shared management it's possible that:
>
> - Previously disabled clocks have been enabled by other entities
> - Rates calculated during clock tree initialization could have changed
>
> Signed-off-by: Randolph Sapp <rs@ti.com>
> ---
>
> I'm hoping this will start a bit of a discussion. I'm still curious why people
> would want to read the rate of an unprepared clock, but there were so many
> logged operations on my test platforms that I assumed it must have some purpose.
>
> Either way, I don't believe cached values should ever be trusted in this
> scenario.
Ignoring the typo in the subject (s/disabled/unprepared/), was there any
feedback regarding this patch?
> drivers/clk/clk.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 85d2f2481acf..9c8b9036b6f6 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1971,8 +1971,16 @@ static void __clk_recalc_rates(struct clk_core *core, bool update_req,
>
> static unsigned long clk_core_get_rate_recalc(struct clk_core *core)
> {
> - if (core && (core->flags & CLK_GET_RATE_NOCACHE))
> - __clk_recalc_rates(core, false, 0);
> + if (core) {
> + bool prepared = clk_core_is_prepared(core);
> +
> + if (core->flags & CLK_GET_RATE_NOCACHE || !prepared) {
> + if (!prepared)
> + pr_debug("%s: rate requested for unprepared clock %s\n",
> + __func__, core->name);
> + __clk_recalc_rates(core, false, 0);
> + }
> + }
>
> return clk_core_get_rate_nolock(core);
> }
next prev parent reply other threads:[~2025-10-07 23:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-03 22:29 [PATCH] clk: do not trust cached rates for disabled clocks rs
2025-10-07 23:58 ` Randolph Sapp [this message]
2025-10-16 11:23 ` Michael Walle
2025-10-17 18:09 ` Randolph Sapp
2025-10-21 22:17 ` Randolph Sapp
2025-10-22 6:23 ` Michael Walle
2025-10-22 23:18 ` Randolph Sapp
2025-10-23 6:44 ` Michael Walle
2025-10-23 8:36 ` Maxime Ripard
2025-10-23 22:55 ` Randolph Sapp
2025-10-24 11:23 ` Maxime Ripard
2025-10-27 23:44 ` Randolph Sapp
2025-10-29 9:05 ` Maxime Ripard
2025-10-29 18:17 ` Randolph Sapp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DDCHX9627F8N.KWJDFIS4TO5O@ti.com \
--to=rs@ti.com \
--cc=linux-clk@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=mwalle@kernel.org \
--cc=sboyd@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.