[PATCH v2] clk: keystone: don't cache clock rate

[a-christidis at ti.com]

From: Michael Walle <mwalle at kernel.org>

The TISCI firmware will return 0 if the clock or consumer is not
enabled although there is a stored value in the firmware. IOW a call to
set rate will work but at get rate will always return 0 if the clock is
disabled.
The clk framework will try to cache the clock rate when it's requested
by a consumer. If the clock or consumer is not enabled at that point,
the cached value is 0, which is wrong. Thus, disable the cache
altogether.

Signed-off-by: Michael Walle <mwalle at kernel.org>
Reviewed-by: Kevin Hilman <khilman at baylibre.com>
Reviewed-by: Randolph Sapp <rs at ti.com>
Reviewed-by: Nishanth Menon <nm at ti.com>
Signed-off-by: Antonios Christidis <a-christidis at ti.com>
---
v2:
- Resent as part of series [1], separated from series per reviewer feedback [2]
- Original patch was sent here [3]
    
[1]: https://lore.kernel.org/all/20260224-gpu_dts-v1-5-cc5ddffe140c@ti.com/
[2]: https://lore.kernel.org/all/20260225010507.flvt775fs5kfe7ez@unknotted/
[3]: https://lore.kernel.org/all/20260109120728.2wku6akxof2ddn4h@tastiness/
---
 drivers/clk/keystone/sci-clk.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c
index 9d5071223f4c..0a1565fdbb3b 100644
--- a/drivers/clk/keystone/sci-clk.c
+++ b/drivers/clk/keystone/sci-clk.c
@@ -333,6 +333,14 @@ static int _sci_clk_build(struct sci_clk_provider *provider,
 
 	init.ops = &sci_clk_ops;
 	init.num_parents = sci_clk->num_parents;
+
+	/*
+	 * A clock rate query to the SCI firmware will return 0 if either the
+	 * clock itself is disabled or the attached device/consumer is disabled.
+	 * This makes it inherently unsuitable for the caching of the clk
+	 * framework.
+	 */
+	init.flags = CLK_GET_RATE_NOCACHE;
 	sci_clk->hw.init = &init;
 
 	ret = devm_clk_hw_register(provider->dev, &sci_clk->hw);

---
base-commit: 17c7841d09ee7d33557fd075562d9289b6018c90
change-id: 20260507-clk-sci-175f398ecdc0

Best regards,
-- 
Antonios Christidis <a-christidis at ti.com>