All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael Walle" <mwalle@kernel.org>
To: "Randolph Sapp" <rs@ti.com>, <mturquette@baylibre.com>,
	<sboyd@kernel.org>
Cc: <linux-clk@vger.kernel.org>, "Maxime Ripard" <mripard@kernel.org>
Subject: Re: [PATCH] clk: do not trust cached rates for disabled clocks
Date: Wed, 22 Oct 2025 08:23:35 +0200	[thread overview]
Message-ID: <DDOMVXFQ82CN.FJ0FMPGMTFPN@kernel.org> (raw)
In-Reply-To: <DDOCJEZSBJ1V.WPWWUAR7M1H9@ti.com>

Hi,

>> Am I correct in my assumption about running clk_get_rate on unprepared clocks
>> though? (That it shouldn't be allowed or, if it is, that the result shouldn't be
>> cached.)
>>
> Any follow up to this Michael? I wanted to be sure this was something the
> subsystem should allow before I look into further workarounds.

I don't know. I'm not that familar with the ccs. My first reaction
was that it's asymmetrical that a .set is allowed (and works for
tisci) and that .get is not allowed. That way you can't read the
hardware clock (or think of a fixed clock, where you want to get the
frequency) before enabling it. I could imagine some devices which
needs to be configured first, before you might turn the clock on.

OTOH Maxime pointed out the comment in the kdoc of clk_get_rate()
which clearly states that it's only valid if the clock is on.

-michael

  reply	other threads:[~2025-10-22  6:29 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
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 [this message]
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=DDOMVXFQ82CN.FJ0FMPGMTFPN@kernel.org \
    --to=mwalle@kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=mripard@kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=rs@ti.com \
    --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.