[PATCH 0/3] firmware: arm_scmi: Miscellaneous improvements

[PATCH 0/3] firmware: arm_scmi: Miscellaneous improvements

[Geert Uytterhoeven]

	Hi all,

This patch series contains miscellaneous improvements for SCMI quirk
handling and SCMI instance iteration.

Thanks for your comments!

Geert Uytterhoeven (3):
  firmware: arm_scmi: quirk: Improve quirk range parsing
  firmware: arm_scmi: quirk: Simplify quirk table iteration
  firmware: arm_scmi: Convert to list_for_each_entry()

 drivers/firmware/arm_scmi/driver.c |  4 +---
 drivers/firmware/arm_scmi/quirks.c | 15 ++++++---------
 2 files changed, 7 insertions(+), 12 deletions(-)

-- 
2.43.0

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[PATCH 1/3] firmware: arm_scmi: quirk: Improve quirk range parsing

[Geert Uytterhoeven]

When a range contains only an end ("-X"), the number string is parsed
twice, as both "sep == first" and "sep != last" are true.  Fix this by
dropping the superfluous number parsing for "sep == first".

This does have a harmless functional impact for the unbounded range:
"-" is now accepted, while it was rejected before.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/firmware/arm_scmi/quirks.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/firmware/arm_scmi/quirks.c b/drivers/firmware/arm_scmi/quirks.c
index 03848283c2a07b72..b1d9cd9fa2427879 100644
--- a/drivers/firmware/arm_scmi/quirks.c
+++ b/drivers/firmware/arm_scmi/quirks.c
@@ -238,16 +238,15 @@ static int scmi_quirk_range_parse(struct scmi_quirk *quirk)
 	if (sep)
 		*sep = '\0';
 
-	if (sep == first) /* -X */
-		ret = kstrtouint(first + 1, 0, &quirk->end_range);
-	else /* X OR X- OR X-y */
+	if (sep != first) /* X OR X- OR X-y */ {
 		ret = kstrtouint(first, 0, &quirk->start_range);
-	if (ret)
-		return ret;
+		if (ret)
+			return ret;
+	}
 
 	if (!sep)
 		quirk->end_range = quirk->start_range;
-	else if (sep != last) /* x-Y */
+	else if (sep != last) /* -X OR x-Y */
 		ret = kstrtouint(sep + 1, 0, &quirk->end_range);
 
 	if (quirk->start_range > quirk->end_range)
-- 
2.43.0

[PATCH 2/3] firmware: arm_scmi: quirk: Simplify quirk table iteration

[Geert Uytterhoeven]

The current table entry is assigned in both the init and loop
expressions of the for-statement.  Merge this into a single assignment
in the conditional expression, to simplify the code.

While at it, make the loop counter unsigned and loop-local.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/firmware/arm_scmi/quirks.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/firmware/arm_scmi/quirks.c b/drivers/firmware/arm_scmi/quirks.c
index b1d9cd9fa2427879..2b38ba3f59a13c9e 100644
--- a/drivers/firmware/arm_scmi/quirks.c
+++ b/drivers/firmware/arm_scmi/quirks.c
@@ -258,10 +258,8 @@ static int scmi_quirk_range_parse(struct scmi_quirk *quirk)
 void scmi_quirks_initialize(void)
 {
 	struct scmi_quirk *quirk;
-	int i;
 
-	for (i = 0, quirk = scmi_quirks_table[0]; quirk;
-	     i++, quirk = scmi_quirks_table[i]) {
+	for (unsigned int i = 0; (quirk = scmi_quirks_table[i]); i++) {
 		int ret;
 
 		ret = scmi_quirk_range_parse(quirk);
-- 
2.43.0

[PATCH 3/3] firmware: arm_scmi: Convert to list_for_each_entry()

[Geert Uytterhoeven]

Simplify the loop in scmi_handle_get() by using list_for_each_entry().

Suggested-by: Marek Vasut <marek.vasut@mailbox.org>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/firmware/arm_scmi/driver.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 57785c0c04241e46..b1bba2c61b728b56 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -2584,13 +2584,11 @@ static bool scmi_is_transport_atomic(const struct scmi_handle *handle,
  */
 static struct scmi_handle *scmi_handle_get(struct device *dev)
 {
-	struct list_head *p;
 	struct scmi_info *info;
 	struct scmi_handle *handle = NULL;
 
 	mutex_lock(&scmi_list_mutex);
-	list_for_each(p, &scmi_list) {
-		info = list_entry(p, struct scmi_info, node);
+	list_for_each_entry(info, &scmi_list, node) {
 		if (dev->parent == info->dev) {
 			info->users++;
 			handle = &info->handle;
-- 
2.43.0

Re: [PATCH 0/3] firmware: arm_scmi: Miscellaneous improvements

[Cristian Marussi]

On Fri, Apr 03, 2026 at 10:41:28AM +0200, Geert Uytterhoeven wrote:
> 	Hi all,

Hi Geert,

thanks for this, first of all.

I was a bit off the keyboard so the delay in my answer.

I will get back at this SCMI/Clocks/Quirks matters in the next few weeks
targeting next rc1-ish...

In a nutshell I was thinking to proceed roughly as follows:

 - respinning a V3 of my original Clock Rates series WITH the addtion
   of your previous fixes series on top (or merged into) BUT DROPPING
   from my original series the patch that triggered a lot of FW panics
   in the wild due to out of spec FWs. (Harden Clock protocol initialization)

 - spinning another NEW series on top of this 'Miscellaneous improvement'
   series of yours, since I want to add, on top of this rework of yours, the
   capability for the Quirk framework to match the same quirk definition
   (static key) against multiple vendors/subvendors/impl....since, as you may
   have noticed :P, I broke a number of boards recently with just one fix
   kernel side BUT all of these issues can be really quirked using some
   common identical quirk snippet to match against all the needed vendors
   (rockchip/nxp/renesas as of now)
   
   ...I have some ugly working hack with which I am experimenting on this
   quirk matching evolution...

   On top of all of this I would then reapply the FW-breaking fix AND all
   the quirks we determine as needed (possibly N matching M vendoes) and
   test as much as possible pushing into for-next...

Then we'll see what Sudeep thinks about all of this, of course.

Thoughts ? Any feedback welcome.

Thanks,
Cristian