Re: [PATCH] clk: do not trust cached rates for disabled clocks

[Randolph Sapp <rs@ti.com>]

On Wed Oct 22, 2025 at 1:23 AM CDT, Michael Walle wrote:
> 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

Yeah, I still don't like the way we handle clock in firmware but I've already
been shut down on that front.

Regardless, there are quite a few drivers right now that use clk_get_rate prior
to preparing the clock. If the kdoc reports clk_get_rate is only valid if the
clock is enabled, should we report a proper warning when this occurs?

- Randolph