[PATCH/RFC] firmware: arm_scmi: Increase SCMI_MAX_NUM_RATES to 64

[PATCH/RFC] firmware: arm_scmi: Increase SCMI_MAX_NUM_RATES to 64

[Geert Uytterhoeven]

Currently, the SCMI clock driver supports up to 16 clock rates.
However, the SCMI specification v3.2 does not explicitly specify the
maximum number of clock rates that can be returned (the theoretical
maximum is 4095 in the first call of the CLOCK_DESCRIBE_RATES command,
followed by 65535 remaining rates in subsequent calls).

In Renesas R-Car X5H SCP FW SDK v4.28.0, some clocks have 32 or 64
rates, which are returned in blocks of maximum 27 entries.  When SCMI
firmware returns more than 16 clock rates, Linux ignores all clock
rates, this reducing functionality of the affected clocks.

Fix this by increasing the maximum number of clock rates to 64.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
This does increase the size of each scmi_clock_info object by 384
bytes, which is way too much on a system with nearly 2000 clocks.
As currrently all scmi_clock_info structures are allocated together as a
single array, the .rates[] member cannot just be converted to a flexible
array, without splitting the allocation.

An alternative solution would be to no longer store all rates, as
proposed by Étienne Carrière in "[PATCH v2 1/2] firmware: arm_scmi: get
only min/max clock rates"
(https://lore.kernel.org/20241203173908.3148794-2-etienne.carriere@foss.st.com)
---
 include/linux/scmi_protocol.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
index aafaac1496b06a6e..707f616d9fc9afbf 100644
--- a/include/linux/scmi_protocol.h
+++ b/include/linux/scmi_protocol.h
@@ -15,7 +15,7 @@
 
 #define SCMI_MAX_STR_SIZE		64
 #define SCMI_SHORT_NAME_MAX_SIZE	16
-#define SCMI_MAX_NUM_RATES		16
+#define SCMI_MAX_NUM_RATES		64
 
 /**
  * struct scmi_revision_info - version information structure
-- 
2.43.0

Re: [PATCH/RFC] firmware: arm_scmi: Increase SCMI_MAX_NUM_RATES to 64

[Cristian Marussi]

On Fri, Feb 20, 2026 at 10:53:31AM +0100, Geert Uytterhoeven wrote:
> Currently, the SCMI clock driver supports up to 16 clock rates.
> However, the SCMI specification v3.2 does not explicitly specify the
> maximum number of clock rates that can be returned (the theoretical
> maximum is 4095 in the first call of the CLOCK_DESCRIBE_RATES command,
> followed by 65535 remaining rates in subsequent calls).

Hi Geert,

> 
> In Renesas R-Car X5H SCP FW SDK v4.28.0, some clocks have 32 or 64
> rates, which are returned in blocks of maximum 27 entries.  When SCMI
> firmware returns more than 16 clock rates, Linux ignores all clock
> rates, this reducing functionality of the affected clocks.
> 
> Fix this by increasing the maximum number of clock rates to 64.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> This does increase the size of each scmi_clock_info object by 384
> bytes, which is way too much on a system with nearly 2000 clocks.
> As currrently all scmi_clock_info structures are allocated together as a
> single array, the .rates[] member cannot just be converted to a flexible
> array, without splitting the allocation.
> 

Indeed the clock protocol does NOT dynamically allocate based on
discovery outcome, like other SCMI protocols do, so that's a waste
of resources that does NOT scale...I am gonna fix this, first, by
allocating dynamically strictly for the effectively discovered
resources (liek other protos do)

> An alternative solution would be to no longer store all rates, as
> proposed by Étienne Carrière in "[PATCH v2 1/2] firmware: arm_scmi: get
> only min/max clock rates"
> (https://lore.kernel.org/20241203173908.3148794-2-etienne.carriere@foss.st.com)

Yes, the other further optimization could be to just query for min/max that
are, indeed, the only rates needed currently, BUT Etienne series open code a
brand new SCMI enumeration instead of rework and use existing SCMI iterators...

...I have an old incomplete series of mine that rework this...not tesetd and
partially working of course :P...I think I will try to give it a respin to
put such optimization on top of the above rework...

I will try to post something this week...let's see

Thanks,
Cristian