Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@kernel.org>
To: arm-scmi@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Cc: Cristian Marussi <cristian.marussi@arm.com>
Subject: [PATCH v2 11/14] firmware: arm_scmi: Clear SystemPower flag on create failure
Date: Wed, 01 Jul 2026 17:52:32 +0100	[thread overview]
Message-ID: <20260701-scmi_core_fixes-v2-11-1f5e85553f73@kernel.org> (raw)
In-Reply-To: <20260701-scmi_core_fixes-v2-0-1f5e85553f73@kernel.org>

__scmi_device_create() reserves the singleton SystemPower protocol
device by setting scmi_syspower_registered before allocating and
registering the SCMI device.

If any later step fails, the function returns NULL but leaves the flag
set. A subsequent retry, for example after probe deferral, then observes
the stale reservation and rejects creation of the SystemPower protocol
device permanently.

Route all failures after the successful reservation through a common
unwind path which clears scmi_syspower_registered again. Keep the
duplicate-device rejection path unchanged because that path did not acquire
the reservation.

Fixes: 2c3e674465e7 ("firmware: arm_scmi: Refactor device create/destroy helpers")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
 drivers/firmware/arm_scmi/bus.c | 22 ++++++++++++----------
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index e1deb1b3011d..cdfcd8e96e93 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -431,6 +431,7 @@ __scmi_device_create(struct device_node *np, struct device *parent,
 {
 	int id, retval;
 	struct scmi_device *scmi_dev;
+	bool syspower = (protocol == SCMI_PROTOCOL_SYSTEM);
 
 	/*
 	 * If the same protocol/name device already exist under the same parent
@@ -446,14 +447,12 @@ __scmi_device_create(struct device_node *np, struct device *parent,
 	}
 
 	/*
-	 * Ignore any possible subsequent failures while creating the device
-	 * since we are doomed anyway at that point; not using a mutex which
-	 * spans across this whole function to keep things simple and to avoid
-	 * to serialize all the __scmi_device_create calls across possibly
-	 * different SCMI server instances (parent)
+	 * Reserve the singleton SystemPower protocol device before
+	 * allocation and registration. This keeps creation simple without
+	 * a mutex spanning the whole function; error paths after the
+	 * reservation must drop it again.
 	 */
-	if (protocol == SCMI_PROTOCOL_SYSTEM &&
-	    atomic_cmpxchg(&scmi_syspower_registered, 0, 1)) {
+	if (syspower && atomic_cmpxchg(&scmi_syspower_registered, 0, 1)) {
 		dev_warn(parent,
 			 "SCMI SystemPower protocol device must be unique !\n");
 		return NULL;
@@ -461,19 +460,19 @@ __scmi_device_create(struct device_node *np, struct device *parent,
 
 	scmi_dev = kzalloc_obj(*scmi_dev);
 	if (!scmi_dev)
-		return NULL;
+		goto clear_syspower;
 
 	scmi_dev->name = kstrdup_const(name ?: "unknown", GFP_KERNEL);
 	if (!scmi_dev->name) {
 		kfree(scmi_dev);
-		return NULL;
+		goto clear_syspower;
 	}
 
 	id = ida_alloc_min(&scmi_bus_id, 1, GFP_KERNEL);
 	if (id < 0) {
 		kfree_const(scmi_dev->name);
 		kfree(scmi_dev);
-		return NULL;
+		goto clear_syspower;
 	}
 
 	scmi_dev->id = id;
@@ -495,6 +494,9 @@ __scmi_device_create(struct device_node *np, struct device *parent,
 put_dev:
 	ida_free(&scmi_bus_id, scmi_dev->id);
 	put_device(&scmi_dev->dev);
+clear_syspower:
+	if (syspower)
+		atomic_set(&scmi_syspower_registered, 0);
 	return NULL;
 }
 

-- 
2.43.0



  parent reply	other threads:[~2026-07-01 16:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-01 16:52 [PATCH v2 00/14] firmware: arm_scmi: Fix SCMI core cleanup paths Sudeep Holla
2026-07-01 16:52 ` [PATCH v2 01/14] firmware: arm_scmi: Fix OF node reference handling Sudeep Holla
2026-07-01 16:52 ` [PATCH v2 02/14] firmware: arm_scmi: Fix transport device teardown lookup Sudeep Holla
2026-07-01 16:52 ` [PATCH v2 03/14] firmware: arm_scmi: Clean up channels on setup failure Sudeep Holla
2026-07-01 16:52 ` [PATCH v2 04/14] firmware: arm_scmi: Fix SCMI device destroy lifetimes Sudeep Holla
2026-07-01 16:52 ` [PATCH v2 05/14] firmware: arm_scmi: Free transport channel on IDR failure Sudeep Holla
2026-07-01 16:52 ` [PATCH v2 06/14] firmware: arm_scmi: Unregister device notifier before IDR teardown Sudeep Holla
2026-07-01 16:52 ` [PATCH v2 07/14] firmware: arm_scmi: Unwind TX receiver mailbox setup failure Sudeep Holla
2026-07-01 16:52 ` [PATCH v2 08/14] firmware: arm_scmi: Unwind P2A " Sudeep Holla
2026-07-01 16:52 ` [PATCH v2 09/14] firmware: arm_scmi: Protect device request lookup with RCU Sudeep Holla
2026-07-01 16:52 ` [PATCH v2 10/14] firmware: arm_scmi: Avoid IDR updates while cleaning channels Sudeep Holla
2026-07-01 16:52 ` Sudeep Holla [this message]
2026-07-01 16:52 ` [PATCH v2 12/14] firmware: arm_scmi: Reject out of range DT protocol IDs Sudeep Holla
2026-07-01 16:52 ` [PATCH v2 13/14] firmware: arm_scmi: Stop channels before notification teardown Sudeep Holla
2026-07-01 16:52 ` [PATCH v2 14/14] firmware: arm_scmi: Publish mailbox cinfo before channel request Sudeep Holla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260701-scmi_core_fixes-v2-11-1f5e85553f73@kernel.org \
    --to=sudeep.holla@kernel.org \
    --cc=arm-scmi@vger.kernel.org \
    --cc=cristian.marussi@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox