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

[Cristian Marussi <cristian.marussi@arm.com>]

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