On Sat, Feb 28, 2026 at 10:29:11AM +0800, Peng Fan wrote:

On Fri, Feb 27, 2026 at 03:32:20PM +0000, Cristian Marussi wrote:

quoted

Leveraging SCMI Clock protocol dynamic discovery capabilities, move away
from the static per-clock rates allocation model in favour of a dynamic
runtime allocation based on effectively discovered resources.

No functional change.

Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
drivers/firmware/arm_scmi/clock.c | 19 ++++++++++++++++---
include/linux/scmi_protocol.h     |  1 -
2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/firmware/arm_scmi/clock.c b/drivers/firmware/arm_scmi/clock.c
index f5d1c608f85a..d0fb5affb5cf 100644
--- a/drivers/firmware/arm_scmi/clock.c
+++ b/drivers/firmware/arm_scmi/clock.c

@@ -161,7 +161,7 @@ struct scmi_clock_desc {

	u32 id;
	bool rate_discrete;
	unsigned int num_rates;
-	u64 rates[SCMI_MAX_NUM_RATES];
+	u64 *rates;
#define	RATE_MIN	0
#define	RATE_MAX	1
#define	RATE_STEP	2

@@ -480,6 +480,18 @@ iter_clk_describe_update_state(struct scmi_iterator_state *st,

			   QUIRK_OUT_OF_SPEC_TRIPLET);
	}

+	if (!st->max_resources) {
+		int num_rates = st->num_returned + st->num_remaining;
+
+		p->clkd->rates = devm_kcalloc(p->dev, num_rates,
+					      sizeof(*p->clkd->rates), GFP_KERNEL);
+		if (!p->clkd->rates)
+			return -ENOMEM;

It may be not related to this patch,
I see scmi_clock_describe_rates_get() does not have return value check
when being called in scmi_clock_protocol_init().

So if devm_kcalloc() fails, there maybe issue without a sanity check
to return value of scmi_clock_describe_rates_get().

Yes I think I saw that...wanted to fix too..and forgot :D 

I will add a fix in V2.

Thanks,
Cristian