[PATCH 0/4] firmware: arm_scmi: Some fixes to address conflicts with fw_devlink

[PATCH 0/4] firmware: arm_scmi: Some fixes to address conflicts with fw_devlink

[Sudeep Holla]

Peng’s [1] identified the problem of multiple SCMI devices sharing one
protocol fwnode. His [2] shows the consequence: the first device owns
the fwnode but does not bind, so fw_devlink can leave consumers deferred
even when another device binds successfully.

This four-patch series reduces those cases within SCMI. It prevents
protocol device creation in exclusive raw mode, stops treating core
created standard devices as driver owned requests, and makes the i.MX
pinctrl driver match the standard `pinctrl` device instead of creating
a second device for the same fwnode. It also omits the `perf` device
when the firmware node does not describe a performance domain provider,
without changing `cpufreq` device creation. IIO/HWMON don't have any
fw_devlink dependency and having two devices shouldn't be an issue.

These changes address the SCMI cases above; they do not provide a
general driver core solution for devices that share a fwnode.

Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>

[1] https://lore.kernel.org/all/20250120-scmi-fwdevlink-v2-0-3af2fa37dbac@nxp.com
[2] https://lore.kernel.org/all/20260928-driver-core-v1-1-0846bb8e0f32@nxp.com

---
Sudeep Holla (4):
      firmware: arm_scmi: Avoid protocol devices in exclusive raw mode
      firmware: arm_scmi: Skip requests for standard protocol devices
      pinctrl: imx: Match the standard SCMI pinctrl device
      firmware: arm_scmi: Skip unused performance-domain devices

 drivers/firmware/arm_scmi/bus.c              | 107 +++++++++++++++++----------
 drivers/pinctrl/freescale/pinctrl-imx-scmi.c |   2 +-
 2 files changed, 68 insertions(+), 41 deletions(-)
---
base-commit: aac4e67d6eb93118cfa70c6562b5f9c81a7042ef
change-id: 20261002-scmi_bus_fixes-19bfe8d3c8e2


-- 
Regards,
Sudeep

[PATCH 1/4] firmware: arm_scmi: Avoid protocol devices in exclusive raw mode

[Sudeep Holla]

Since standard protocol devices are created without a driver request,
rejecting SCMI driver registration is no longer enough to prevent them
from appearing when raw mode is enabled without coexistence.

When raw-mode debugfs setup succeeds, scmi_probe() returns success
before protocol enumeration, so it does not normally create those
devices. That early return is not sufficient: scmi_device_create() is
exported and can be called later.

Skip protocol-device creation in exclusive raw mode, including named
non-transport requests. Keep named transport devices so raw mode can
still set up its channels. Share the raw-mode condition and transport
name check with the existing bus paths.

Cc: Hans de Goede <johannes.goede@oss.qualcomm.com>
Fixes: aac4e67d6eb9 ("firmware: arm_scmi: Always create devices for standard protocols")
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
 drivers/firmware/arm_scmi/bus.c | 23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index 25197197db8e..f2e2ed56bc32 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -36,6 +36,12 @@ struct scmi_requested_dev {
 /* Track globally the SCMI SystemPower protocol device. */
 static struct scmi_device *scmi_syspower_registered;
 
+static bool scmi_raw_mode_only(void)
+{
+	return IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT) &&
+	       !IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT_COEX);
+}
+
 /**
  * scmi_protocol_device_request  - Helper to request a device
  *
@@ -60,8 +66,7 @@ static int scmi_protocol_device_request(const struct scmi_device_id *id_table)
 	pr_debug("Requesting SCMI device (%s) for protocol %x\n",
 		 id_table->name, id_table->protocol_id);
 
-	if (IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT) &&
-	    !IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT_COEX)) {
+	if (scmi_raw_mode_only()) {
 		pr_warn("SCMI Raw mode active. Rejecting '%s'/0x%02X\n",
 			id_table->name, id_table->protocol_id);
 		return -EINVAL;
@@ -210,12 +215,17 @@ scmi_protocol_table_unregister(const struct scmi_device_id *id_table)
 		scmi_protocol_device_unrequest(entry);
 }
 
-static bool scmi_device_is_transport(const struct scmi_device *scmi_dev)
+static bool scmi_device_name_is_transport(const char *name)
 {
-	return !strncmp(scmi_dev->name, SCMI_TRANSPORT_DEVNAME_PREFIX,
+	return !strncmp(name, SCMI_TRANSPORT_DEVNAME_PREFIX,
 			strlen(SCMI_TRANSPORT_DEVNAME_PREFIX));
 }
 
+static bool scmi_device_is_transport(const struct scmi_device *scmi_dev)
+{
+	return scmi_device_name_is_transport(scmi_dev->name);
+}
+
 static int __scmi_dev_match_by_id_table(struct scmi_device *scmi_dev,
 					const struct scmi_device_id *id_table,
 					bool skip_transport)
@@ -591,6 +601,11 @@ struct scmi_device *scmi_device_create(struct fwnode_handle *fwnode,
 	struct scmi_requested_dev *rdev;
 	struct scmi_device *sdev, *scmi_dev = NULL;
 
+	/* Exclusive raw mode still needs transport devices for its channels. */
+	if (scmi_raw_mode_only() &&
+	    (!name || !scmi_device_name_is_transport(name)))
+		return NULL;
+
 	if (name)
 		return _scmi_device_create(fwnode, parent, protocol, name);
 

-- 
2.43.0

Re: [PATCH 1/4] firmware: arm_scmi: Avoid protocol devices in exclusive raw mode

[Hans de Goede]

Hi Sudeep,

On 2-Oct-26 11:36, Sudeep Holla wrote:
> Since standard protocol devices are created without a driver request,
> rejecting SCMI driver registration is no longer enough to prevent them
> from appearing when raw mode is enabled without coexistence.
> 
> When raw-mode debugfs setup succeeds, scmi_probe() returns success
> before protocol enumeration, so it does not normally create those
> devices. That early return is not sufficient: scmi_device_create() is
> exported and can be called later.
> 
> Skip protocol-device creation in exclusive raw mode, including named
> non-transport requests. Keep named transport devices so raw mode can
> still set up its channels. Share the raw-mode condition and transport
> name check with the existing bus paths.
> 
> Cc: Hans de Goede <johannes.goede@oss.qualcomm.com>
> Fixes: aac4e67d6eb9 ("firmware: arm_scmi: Always create devices for standard protocols")
> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>

Regards,

Hans



> ---
>  drivers/firmware/arm_scmi/bus.c | 23 +++++++++++++++++++----
>  1 file changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
> index 25197197db8e..f2e2ed56bc32 100644
> --- a/drivers/firmware/arm_scmi/bus.c
> +++ b/drivers/firmware/arm_scmi/bus.c
> @@ -36,6 +36,12 @@ struct scmi_requested_dev {
>  /* Track globally the SCMI SystemPower protocol device. */
>  static struct scmi_device *scmi_syspower_registered;
>  
> +static bool scmi_raw_mode_only(void)
> +{
> +	return IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT) &&
> +	       !IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT_COEX);
> +}
> +
>  /**
>   * scmi_protocol_device_request  - Helper to request a device
>   *
> @@ -60,8 +66,7 @@ static int scmi_protocol_device_request(const struct scmi_device_id *id_table)
>  	pr_debug("Requesting SCMI device (%s) for protocol %x\n",
>  		 id_table->name, id_table->protocol_id);
>  
> -	if (IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT) &&
> -	    !IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT_COEX)) {
> +	if (scmi_raw_mode_only()) {
>  		pr_warn("SCMI Raw mode active. Rejecting '%s'/0x%02X\n",
>  			id_table->name, id_table->protocol_id);
>  		return -EINVAL;
> @@ -210,12 +215,17 @@ scmi_protocol_table_unregister(const struct scmi_device_id *id_table)
>  		scmi_protocol_device_unrequest(entry);
>  }
>  
> -static bool scmi_device_is_transport(const struct scmi_device *scmi_dev)
> +static bool scmi_device_name_is_transport(const char *name)
>  {
> -	return !strncmp(scmi_dev->name, SCMI_TRANSPORT_DEVNAME_PREFIX,
> +	return !strncmp(name, SCMI_TRANSPORT_DEVNAME_PREFIX,
>  			strlen(SCMI_TRANSPORT_DEVNAME_PREFIX));
>  }
>  
> +static bool scmi_device_is_transport(const struct scmi_device *scmi_dev)
> +{
> +	return scmi_device_name_is_transport(scmi_dev->name);
> +}
> +
>  static int __scmi_dev_match_by_id_table(struct scmi_device *scmi_dev,
>  					const struct scmi_device_id *id_table,
>  					bool skip_transport)
> @@ -591,6 +601,11 @@ struct scmi_device *scmi_device_create(struct fwnode_handle *fwnode,
>  	struct scmi_requested_dev *rdev;
>  	struct scmi_device *sdev, *scmi_dev = NULL;
>  
> +	/* Exclusive raw mode still needs transport devices for its channels. */
> +	if (scmi_raw_mode_only() &&
> +	    (!name || !scmi_device_name_is_transport(name)))
> +		return NULL;
> +
>  	if (name)
>  		return _scmi_device_create(fwnode, parent, protocol, name);
>  
> 

[PATCH 2/4] firmware: arm_scmi: Skip requests for standard protocol devices

[Sudeep Holla]

The SCMI core creates devices for the standard protocol IDs during
protocol enumeration, without waiting for an SCMI driver request.
Recording a request for one of these devices also rejects a second
driver registering the same protocol/name pair.

When the first driver unregisters, unrequesting that pair destroys the
core-created device. No other driver can be bound to it at that point,
but removing it also removes the device that a later driver could bind
to or use for module autoloading.

Skip request tracking for standard devices. Keep request tracking and
rollback for nonstandard devices unchanged.

Cc: Hans de Goede <johannes.goede@oss.qualcomm.com>
Fixes: aac4e67d6eb9 ("firmware: arm_scmi: Always create devices for standard protocols")
Reported-by: Peng Fan <peng.fan@oss.nxp.com>
Closes: https://lore.kernel.org/all/20260928-driver-core-v1-1-0846bb8e0f32@nxp.com
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
 drivers/firmware/arm_scmi/bus.c | 73 +++++++++++++++++++++++------------------
 1 file changed, 41 insertions(+), 32 deletions(-)

diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index f2e2ed56bc32..230ee9f6f1aa 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -186,12 +186,44 @@ static void scmi_protocol_device_unrequest(const struct scmi_device_id *id_table
 	}
 }
 
+/* Standard protocols table */
+static const struct scmi_device_id scmi_std_id_table[] = {
+	{ SCMI_PROTOCOL_POWER, "genpd" },
+	{ SCMI_PROTOCOL_SYSTEM, "syspower" },
+	{ SCMI_PROTOCOL_PERF, "perf" },
+	{ SCMI_PROTOCOL_PERF, "cpufreq" },
+	{ SCMI_PROTOCOL_CLOCK, "clocks" },
+	{ SCMI_PROTOCOL_SENSOR, "hwmon" },
+	{ SCMI_PROTOCOL_SENSOR, "iiodev" },
+	{ SCMI_PROTOCOL_RESET, "reset" },
+	{ SCMI_PROTOCOL_VOLTAGE, "regulator" },
+	{ SCMI_PROTOCOL_POWERCAP, "powercap" },
+	{ SCMI_PROTOCOL_PINCTRL, "pinctrl" },
+	{ SCMI_PROTOCOL_PINCTRL, "pinctrl-imx" },
+	{ },
+};
+
+static bool scmi_device_id_in_std_id_table(const struct scmi_device_id *id)
+{
+	for (int i = 0; scmi_std_id_table[i].name[0]; i++) {
+		if (scmi_std_id_table[i].protocol_id == id->protocol_id &&
+		    !strcmp(scmi_std_id_table[i].name, id->name))
+			return true;
+	}
+
+	return false;
+}
+
 static int scmi_protocol_table_register(const struct scmi_device_id *id_table)
 {
 	const struct scmi_device_id *entry;
 	int ret;
 
 	for (entry = id_table; entry->name[0]; entry++) {
+		/* Skip standard devices as they are created unconditionally */
+		if (scmi_device_id_in_std_id_table(entry))
+			continue;
+
 		ret = scmi_protocol_device_request(entry);
 		if (ret)
 			goto err_unrequest;
@@ -200,8 +232,11 @@ static int scmi_protocol_table_register(const struct scmi_device_id *id_table)
 	return 0;
 
 err_unrequest:
-	while (entry != id_table)
-		scmi_protocol_device_unrequest(--entry);
+	while (entry != id_table) {
+		--entry;
+		if (!scmi_device_id_in_std_id_table(entry))
+			scmi_protocol_device_unrequest(entry);
+	}
 
 	return ret;
 }
@@ -211,8 +246,10 @@ scmi_protocol_table_unregister(const struct scmi_device_id *id_table)
 {
 	const struct scmi_device_id *entry;
 
-	for (entry = id_table; entry->name[0]; entry++)
-		scmi_protocol_device_unrequest(entry);
+	for (entry = id_table; entry->name[0]; entry++) {
+		if (!scmi_device_id_in_std_id_table(entry))
+			scmi_protocol_device_unrequest(entry);
+	}
 }
 
 static bool scmi_device_name_is_transport(const char *name)
@@ -542,34 +579,6 @@ _scmi_device_create(struct fwnode_handle *fwnode, struct device *parent,
 	return sdev;
 }
 
-/* Standard protocols table */
-static const struct scmi_device_id scmi_std_id_table[] = {
-	{ SCMI_PROTOCOL_POWER, "genpd" },
-	{ SCMI_PROTOCOL_SYSTEM, "syspower" },
-	{ SCMI_PROTOCOL_PERF, "perf" },
-	{ SCMI_PROTOCOL_PERF, "cpufreq" },
-	{ SCMI_PROTOCOL_CLOCK, "clocks" },
-	{ SCMI_PROTOCOL_SENSOR, "hwmon" },
-	{ SCMI_PROTOCOL_SENSOR, "iiodev" },
-	{ SCMI_PROTOCOL_RESET, "reset" },
-	{ SCMI_PROTOCOL_VOLTAGE, "regulator" },
-	{ SCMI_PROTOCOL_POWERCAP, "powercap" },
-	{ SCMI_PROTOCOL_PINCTRL, "pinctrl" },
-	{ SCMI_PROTOCOL_PINCTRL, "pinctrl-imx" },
-	{ },
-};
-
-static bool scmi_device_id_in_std_id_table(const struct scmi_device_id *id)
-{
-	for (int i = 0; scmi_std_id_table[i].name[0]; i++) {
-		if (scmi_std_id_table[i].protocol_id == id->protocol_id &&
-		    !strcmp(scmi_std_id_table[i].name, id->name))
-			return true;
-	}
-
-	return false;
-}
-
 /**
  * scmi_device_create  - A method to create one or more SCMI devices
  *

-- 
2.43.0

Re: [PATCH 2/4] firmware: arm_scmi: Skip requests for standard protocol devices

[Hans de Goede]

Hi Sudeep,

On 2-Oct-26 11:36, Sudeep Holla wrote:
> The SCMI core creates devices for the standard protocol IDs during
> protocol enumeration, without waiting for an SCMI driver request.
> Recording a request for one of these devices also rejects a second
> driver registering the same protocol/name pair.

Right, but that was also the case before:

aac4e67d6eb9 ("firmware: arm_scmi: Always create devices for standard protocols")

I actually went for the "static" device creation instead of automatically
adding requests to the requested-devices list to keep the behavior
of rejecting a second driver claiming the same device-id in place.

> When the first driver unregisters, unrequesting that pair destroys the
> core-created device.

Correct this was pointed out by Shashiko, but I deemed this ok because
I assumed that if the driver is manually unregistered (rmmod) it will
also be manually insmod-ed again.

This assumes that re-registering the driver recreates the standard
protocol devices as it did before and I do not see why it would not.

Re-registering the driver leads to the following call-chain:

scmi_driver_register()
scmi_protocol_table_register()
scmi_protocol_device_request()
blocking_notifier_call_chain(SCMI_BUS_NOTIFY_DEVICE_REQUEST, id_table)
scmi_device_request_notifier(SCMI_BUS_NOTIFY_DEVICE_REQUEST, id_table)
scmi_create_protocol_devices(id_table->protocol_id, id_table->name)
scmi_device_create(prot_id, name)

And since the name argument to scmi_device_create() is
not NULL we enter this path there:

        if (name)
                return _scmi_device_create(np, parent, protocol, name);

Just as before aac4e67d6eb9 ("firmware: arm_scmi: Always create devices
for standard protocols") and the standard-proto device will be created.

So AFAICT a manual insmod/modprobe should work and I just tested:
rmmod scmi_cpufreq + modprobe scmi_cpufreq with the autoload patches
in place and that makes the cpufreq SCMI bus device go away and
re-appear as expected.

The only thing which won't work is:

rmmod standard-proto-driver
udevadm trigger

to make udev reload the module after a manual rmmod, but I consider
that a case of 'doctor it hurts when I do foo' with as answer:
'Well then do not do foo'.

> No other driver can be bound to it at that point,
> but removing it also removes the device that a later driver could bind
> to or use for module autoloading.

While correct, simply re-registering the driver fixes the device
not being there, see above.

> Skip request tracking for standard devices. Keep request tracking and
> rollback for nonstandard devices unchanged.

This has the downside that it will allow drivers to claim duplicate-ids
for standard-proto devices.

That downside is pretty much why aac4e67d6eb9 ("firmware: arm_scmi:
Always create devices for standard protocols") does things the way
it does.

If we want something like this patch, then my suggestion would be to
make scmi_protocol_device_unrequest() skip the
blocking_notifier_call_chain(SCMI_BUS_NOTIFY_DEVICE_UNREQUEST) call
for standard protocol devices, but otherwise keep them on the request
list to keep the detection of duplicate device-ids.

But I'm not sure even that is necessary, my change deliberately only
touched the scmi_device_create(name = NULL) path to make sure
the devices are initially created. Future driver unregistering leading
to them going away as before is not really a problem IMHO.

Regards,

Hans




> 
> Cc: Hans de Goede <johannes.goede@oss.qualcomm.com>
> Fixes: aac4e67d6eb9 ("firmware: arm_scmi: Always create devices for standard protocols")
> Reported-by: Peng Fan <peng.fan@oss.nxp.com>
> Closes: https://lore.kernel.org/all/20260928-driver-core-v1-1-0846bb8e0f32@nxp.com
> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
> ---
>  drivers/firmware/arm_scmi/bus.c | 73 +++++++++++++++++++++++------------------
>  1 file changed, 41 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
> index f2e2ed56bc32..230ee9f6f1aa 100644
> --- a/drivers/firmware/arm_scmi/bus.c
> +++ b/drivers/firmware/arm_scmi/bus.c
> @@ -186,12 +186,44 @@ static void scmi_protocol_device_unrequest(const struct scmi_device_id *id_table
>  	}
>  }
>  
> +/* Standard protocols table */
> +static const struct scmi_device_id scmi_std_id_table[] = {
> +	{ SCMI_PROTOCOL_POWER, "genpd" },
> +	{ SCMI_PROTOCOL_SYSTEM, "syspower" },
> +	{ SCMI_PROTOCOL_PERF, "perf" },
> +	{ SCMI_PROTOCOL_PERF, "cpufreq" },
> +	{ SCMI_PROTOCOL_CLOCK, "clocks" },
> +	{ SCMI_PROTOCOL_SENSOR, "hwmon" },
> +	{ SCMI_PROTOCOL_SENSOR, "iiodev" },
> +	{ SCMI_PROTOCOL_RESET, "reset" },
> +	{ SCMI_PROTOCOL_VOLTAGE, "regulator" },
> +	{ SCMI_PROTOCOL_POWERCAP, "powercap" },
> +	{ SCMI_PROTOCOL_PINCTRL, "pinctrl" },
> +	{ SCMI_PROTOCOL_PINCTRL, "pinctrl-imx" },
> +	{ },
> +};
> +
> +static bool scmi_device_id_in_std_id_table(const struct scmi_device_id *id)
> +{
> +	for (int i = 0; scmi_std_id_table[i].name[0]; i++) {
> +		if (scmi_std_id_table[i].protocol_id == id->protocol_id &&
> +		    !strcmp(scmi_std_id_table[i].name, id->name))
> +			return true;
> +	}
> +
> +	return false;
> +}
> +
>  static int scmi_protocol_table_register(const struct scmi_device_id *id_table)
>  {
>  	const struct scmi_device_id *entry;
>  	int ret;
>  
>  	for (entry = id_table; entry->name[0]; entry++) {
> +		/* Skip standard devices as they are created unconditionally */
> +		if (scmi_device_id_in_std_id_table(entry))
> +			continue;
> +
>  		ret = scmi_protocol_device_request(entry);
>  		if (ret)
>  			goto err_unrequest;
> @@ -200,8 +232,11 @@ static int scmi_protocol_table_register(const struct scmi_device_id *id_table)
>  	return 0;
>  
>  err_unrequest:
> -	while (entry != id_table)
> -		scmi_protocol_device_unrequest(--entry);
> +	while (entry != id_table) {
> +		--entry;
> +		if (!scmi_device_id_in_std_id_table(entry))
> +			scmi_protocol_device_unrequest(entry);
> +	}
>  
>  	return ret;
>  }
> @@ -211,8 +246,10 @@ scmi_protocol_table_unregister(const struct scmi_device_id *id_table)
>  {
>  	const struct scmi_device_id *entry;
>  
> -	for (entry = id_table; entry->name[0]; entry++)
> -		scmi_protocol_device_unrequest(entry);
> +	for (entry = id_table; entry->name[0]; entry++) {
> +		if (!scmi_device_id_in_std_id_table(entry))
> +			scmi_protocol_device_unrequest(entry);
> +	}
>  }
>  
>  static bool scmi_device_name_is_transport(const char *name)
> @@ -542,34 +579,6 @@ _scmi_device_create(struct fwnode_handle *fwnode, struct device *parent,
>  	return sdev;
>  }
>  
> -/* Standard protocols table */
> -static const struct scmi_device_id scmi_std_id_table[] = {
> -	{ SCMI_PROTOCOL_POWER, "genpd" },
> -	{ SCMI_PROTOCOL_SYSTEM, "syspower" },
> -	{ SCMI_PROTOCOL_PERF, "perf" },
> -	{ SCMI_PROTOCOL_PERF, "cpufreq" },
> -	{ SCMI_PROTOCOL_CLOCK, "clocks" },
> -	{ SCMI_PROTOCOL_SENSOR, "hwmon" },
> -	{ SCMI_PROTOCOL_SENSOR, "iiodev" },
> -	{ SCMI_PROTOCOL_RESET, "reset" },
> -	{ SCMI_PROTOCOL_VOLTAGE, "regulator" },
> -	{ SCMI_PROTOCOL_POWERCAP, "powercap" },
> -	{ SCMI_PROTOCOL_PINCTRL, "pinctrl" },
> -	{ SCMI_PROTOCOL_PINCTRL, "pinctrl-imx" },
> -	{ },
> -};
> -
> -static bool scmi_device_id_in_std_id_table(const struct scmi_device_id *id)
> -{
> -	for (int i = 0; scmi_std_id_table[i].name[0]; i++) {
> -		if (scmi_std_id_table[i].protocol_id == id->protocol_id &&
> -		    !strcmp(scmi_std_id_table[i].name, id->name))
> -			return true;
> -	}
> -
> -	return false;
> -}
> -
>  /**
>   * scmi_device_create  - A method to create one or more SCMI devices
>   *
> 

Re: [PATCH 2/4] firmware: arm_scmi: Skip requests for standard protocol devices

[Sudeep Holla]

On Fri, Oct 02, 2026 at 12:18:57PM +0200, Hans de Goede wrote:
> Hi Sudeep,
> 
> On 2-Oct-26 11:36, Sudeep Holla wrote:
> > The SCMI core creates devices for the standard protocol IDs during
> > protocol enumeration, without waiting for an SCMI driver request.
> > Recording a request for one of these devices also rejects a second
> > driver registering the same protocol/name pair.
> 
> Right, but that was also the case before:
> 
> aac4e67d6eb9 ("firmware: arm_scmi: Always create devices for standard protocols")
> 

Agreed, I was thinking of dropping fixes as I was not 100% sure if that
is fair but just slipped my mind before sending it out. I am happy to drop
it.

> I actually went for the "static" device creation instead of automatically
> adding requests to the requested-devices list to keep the behavior
> of rejecting a second driver claiming the same device-id in place.
> 
> > When the first driver unregisters, unrequesting that pair destroys the
> > core-created device.
> 
> Correct this was pointed out by Shashiko, but I deemed this ok because
> I assumed that if the driver is manually unregistered (rmmod) it will
> also be manually insmod-ed again.
> 
> This assumes that re-registering the driver recreates the standard
> protocol devices as it did before and I do not see why it would not.
> 
> Re-registering the driver leads to the following call-chain:
> 
> scmi_driver_register()
> scmi_protocol_table_register()
> scmi_protocol_device_request()
> blocking_notifier_call_chain(SCMI_BUS_NOTIFY_DEVICE_REQUEST, id_table)
> scmi_device_request_notifier(SCMI_BUS_NOTIFY_DEVICE_REQUEST, id_table)
> scmi_create_protocol_devices(id_table->protocol_id, id_table->name)
> scmi_device_create(prot_id, name)
> 
> And since the name argument to scmi_device_create() is
> not NULL we enter this path there:
> 
>         if (name)
>                 return _scmi_device_create(np, parent, protocol, name);
> 
> Just as before aac4e67d6eb9 ("firmware: arm_scmi: Always create devices
> for standard protocols") and the standard-proto device will be created.
> 
> So AFAICT a manual insmod/modprobe should work and I just tested:
> rmmod scmi_cpufreq + modprobe scmi_cpufreq with the autoload patches
> in place and that makes the cpufreq SCMI bus device go away and
> re-appear as expected.
> 
> The only thing which won't work is:
> 
> rmmod standard-proto-driver
> udevadm trigger
> 
> to make udev reload the module after a manual rmmod, but I consider
> that a case of 'doctor it hurts when I do foo' with as answer:
> 'Well then do not do foo'.
> 
> > No other driver can be bound to it at that point,
> > but removing it also removes the device that a later driver could bind
> > to or use for module autoloading.
> 
> While correct, simply re-registering the driver fixes the device
> not being there, see above.
> 

Yes but IIUC it take the path where bus is tracking and keeping records
like it does for non-standard protocol right ? I just want to avoid that
completely as it is hard to read and may be bit confusing as the std
device creation can take 2 different paths.

> > Skip request tracking for standard devices. Keep request tracking and
> > rollback for nonstandard devices unchanged.
> 
> This has the downside that it will allow drivers to claim duplicate-ids
> for standard-proto devices.
> 

Sorry I don't understand what does the above mean.

> That downside is pretty much why aac4e67d6eb9 ("firmware: arm_scmi:
> Always create devices for standard protocols") does things the way
> it does.
> 
> If we want something like this patch, then my suggestion would be to
> make scmi_protocol_device_unrequest() skip the
> blocking_notifier_call_chain(SCMI_BUS_NOTIFY_DEVICE_UNREQUEST) call
> for standard protocol devices, but otherwise keep them on the request
> list to keep the detection of duplicate device-ids.
> 

Ah, is this the same reference of duplicate-ids for std-proto devices
made above ? If so, I understand what you mean now. I agree we need
to fix that too. I simply don't like keeping 2 possible paths or
device creation for std proto devices as I feel it will be troublesome
in the future.

> But I'm not sure even that is necessary, my change deliberately only
> touched the scmi_device_create(name = NULL) path to make sure
> the devices are initially created. Future driver unregistering leading
> to them going away as before is not really a problem IMHO.
> 

Do you mean, you prefer to keep 2 paths for std protocol device creation ?

-- 
Regards,
Sudeep

Re: [PATCH 2/4] firmware: arm_scmi: Skip requests for standard protocol devices

[Sudeep Holla]

On Fri, Oct 02, 2026 at 01:50:44PM +0100, Sudeep Holla wrote:
> On Fri, Oct 02, 2026 at 12:18:57PM +0200, Hans de Goede wrote:
> 

[...]

> > That downside is pretty much why aac4e67d6eb9 ("firmware: arm_scmi:
> > Always create devices for standard protocols") does things the way
> > it does.
> > 
> > If we want something like this patch, then my suggestion would be to
> > make scmi_protocol_device_unrequest() skip the
> > blocking_notifier_call_chain(SCMI_BUS_NOTIFY_DEVICE_UNREQUEST) call
> > for standard protocol devices, but otherwise keep them on the request
> > list to keep the detection of duplicate device-ids.
> > 
> 
> Ah, is this the same reference of duplicate-ids for std-proto devices
> made above ? If so, I understand what you mean now. I agree we need
> to fix that too. I simply don't like keeping 2 possible paths or
> device creation for std proto devices as I feel it will be troublesome
> in the future.
> 

No, I am actually lost. I am probably not able to understand the case
you are explaining, sorry.

-- 
Regards,
Sudeep

Re: [PATCH 2/4] firmware: arm_scmi: Skip requests for standard protocol devices

[Hans de Goede]

Hi,

On 2-Oct-26 2:50 PM, Sudeep Holla wrote:
> On Fri, Oct 02, 2026 at 12:18:57PM +0200, Hans de Goede wrote:
>> Hi Sudeep,
>>
>> On 2-Oct-26 11:36, Sudeep Holla wrote:

<snip>

>> While correct, simply re-registering the driver fixes the device
>> not being there, see above.
>>
> 
> Yes but IIUC it take the path where bus is tracking and keeping records
> like it does for non-standard protocol right ?

Correct.

> I just want to avoid that
> completely as it is hard to read and may be bit confusing as the std
> device creation can take 2 different paths.

Ah, I see that makes sense.

>>> Skip request tracking for standard devices. Keep request tracking and
>>> rollback for nonstandard devices unchanged.
>>
>> This has the downside that it will allow drivers to claim duplicate-ids
>> for standard-proto devices.
>>
> 
> Sorry I don't understand what does the above mean.

What I mean is that 2 drivers can now claim the same <proto-id, name>
tupple and both will successfully register.

>> That downside is pretty much why aac4e67d6eb9 ("firmware: arm_scmi:
>> Always create devices for standard protocols") does things the way
>> it does.
>>
>> If we want something like this patch, then my suggestion would be to
>> make scmi_protocol_device_unrequest() skip the
>> blocking_notifier_call_chain(SCMI_BUS_NOTIFY_DEVICE_UNREQUEST) call
>> for standard protocol devices, but otherwise keep them on the request
>> list to keep the detection of duplicate device-ids.
>>
> 
> Ah, is this the same reference of duplicate-ids for std-proto devices
> made above ?

Yes.

> If so, I understand what you mean now. I agree we need
> to fix that too. I simply don't like keeping 2 possible paths or
> device creation for std proto devices as I feel it will be troublesome
> in the future.

Ok, I see. 

>> But I'm not sure even that is necessary, my change deliberately only
>> touched the scmi_device_create(name = NULL) path to make sure
>> the devices are initially created. Future driver unregistering leading
>> to them going away as before is not really a problem IMHO.
>>
> 
> Do you mean, you prefer to keep 2 paths for std protocol device creation ?
 
Well we've 2 different paths for non std protocol device creation too,
depending on if the protocol-id shows up before or after a driver
requesting the device arrives.

So I'm not convinced we really need to fix anything, but if you want
to move to only 1 path for std protocol device creation that I've no
objection against that.

Note that other busses do accept multiple drivers claiming the same
device-id. With the first one to probe successfully winning. So we
could also proceed with that patch as is.

Regards,

Hans

Re: [PATCH 2/4] firmware: arm_scmi: Skip requests for standard protocol devices

[Sudeep Holla]

On Fri, Oct 02, 2026 at 03:40:44PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 2-Oct-26 2:50 PM, Sudeep Holla wrote:
> > On Fri, Oct 02, 2026 at 12:18:57PM +0200, Hans de Goede wrote:
> >> Hi Sudeep,
> >>
> >> On 2-Oct-26 11:36, Sudeep Holla wrote:
> 
> <snip>
> 
> >> While correct, simply re-registering the driver fixes the device
> >> not being there, see above.
> >>
> > 
> > Yes but IIUC it take the path where bus is tracking and keeping records
> > like it does for non-standard protocol right ?
> 
> Correct.
> 
> > I just want to avoid that
> > completely as it is hard to read and may be bit confusing as the std
> > device creation can take 2 different paths.
> 
> Ah, I see that makes sense.
> 
> >>> Skip request tracking for standard devices. Keep request tracking and
> >>> rollback for nonstandard devices unchanged.
> >>
> >> This has the downside that it will allow drivers to claim duplicate-ids
> >> for standard-proto devices.
> >>
> > 
> > Sorry I don't understand what does the above mean.
> 
> What I mean is that 2 drivers can now claim the same <proto-id, name>
> tupple and both will successfully register.
> 

Oh well, we want that. We tried avoiding that with different name but
2 device with same fwnode is causing issues. The exception is pinctl-imx
driver which triggered all these. I understand the concern but it is
hard restrict the usage of SCMI in some ways as it gets deployed in
more platforms. Happy to hear any alternative solution for the longer
term if it is hard in short term.

> >> That downside is pretty much why aac4e67d6eb9 ("firmware: arm_scmi:
> >> Always create devices for standard protocols") does things the way
> >> it does.
> >>
> >> If we want something like this patch, then my suggestion would be to
> >> make scmi_protocol_device_unrequest() skip the
> >> blocking_notifier_call_chain(SCMI_BUS_NOTIFY_DEVICE_UNREQUEST) call
> >> for standard protocol devices, but otherwise keep them on the request
> >> list to keep the detection of duplicate device-ids.
> >>
> > 
> > Ah, is this the same reference of duplicate-ids for std-proto devices
> > made above ?
> 
> Yes.
> 

Thanks!

> > If so, I understand what you mean now. I agree we need
> > to fix that too. I simply don't like keeping 2 possible paths or
> > device creation for std proto devices as I feel it will be troublesome
> > in the future.
> 
> Ok, I see.
> 
> >> But I'm not sure even that is necessary, my change deliberately only
> >> touched the scmi_device_create(name = NULL) path to make sure
> >> the devices are initially created. Future driver unregistering leading
> >> to them going away as before is not really a problem IMHO.
> >>
> > 
> > Do you mean, you prefer to keep 2 paths for std protocol device creation ?
>  
> Well we've 2 different paths for non std protocol device creation too,
> depending on if the protocol-id shows up before or after a driver
> requesting the device arrives.
> 

Agreed, but for std protocol we are sticking with enumeration time now.

> So I'm not convinced we really need to fix anything, but if you want
> to move to only 1 path for std protocol device creation that I've no
> objection against that.
> 

I think you missed the fact we are supporting the 2 different drivers
with same <proto_id, name>. You worded it differently and sorry for not
getting that early.

> Note that other busses do accept multiple drivers claiming the same
> device-id. With the first one to probe successfully winning. So we
> could also proceed with that patch as is.
> 

Indeed, that is the only way it can be made work. In this case we have
block list in scmi-pinctl driver for i.MX platform and that's how they
have their own driver probed successfully. It was quite a ride in getting
that merged after all attempts to have single generic driver failed 🙁.
It is created problems as we created multiple devices sharing same
fwnode unfortunately. This series solved the issue by trying to remove
multiple device creation with same fwnode where possible for that reason.
Hope that clarifies things, sorry I realise the context in the cover letter
was bit short to give overall picture of issue and history on this.

-- 
Regards,
Sudeep

Re: [PATCH 2/4] firmware: arm_scmi: Skip requests for standard protocol devices

[Hans de Goede]

Hi,

On 2-Oct-26 15:56, Sudeep Holla wrote:
> On Fri, Oct 02, 2026 at 03:40:44PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 2-Oct-26 2:50 PM, Sudeep Holla wrote:
>>> On Fri, Oct 02, 2026 at 12:18:57PM +0200, Hans de Goede wrote:
>>>> Hi Sudeep,
>>>>
>>>> On 2-Oct-26 11:36, Sudeep Holla wrote:
>>
>> <snip>
>>
>>>> While correct, simply re-registering the driver fixes the device
>>>> not being there, see above.
>>>>
>>>
>>> Yes but IIUC it take the path where bus is tracking and keeping records
>>> like it does for non-standard protocol right ?
>>
>> Correct.
>>
>>> I just want to avoid that
>>> completely as it is hard to read and may be bit confusing as the std
>>> device creation can take 2 different paths.
>>
>> Ah, I see that makes sense.
>>
>>>>> Skip request tracking for standard devices. Keep request tracking and
>>>>> rollback for nonstandard devices unchanged.
>>>>
>>>> This has the downside that it will allow drivers to claim duplicate-ids
>>>> for standard-proto devices.
>>>>
>>>
>>> Sorry I don't understand what does the above mean.
>>
>> What I mean is that 2 drivers can now claim the same <proto-id, name>
>> tupple and both will successfully register.
>>
> 
> Oh well, we want that. We tried avoiding that with different name but
> 2 device with same fwnode is causing issues.

Ah I see, if we want to allow multiple drivers claiming the same
device-id. Then this patch is fine as as.

> The exception is pinctl-imx
> driver which triggered all these. I understand the concern but it is
> hard restrict the usage of SCMI in some ways as it gets deployed in
> more platforms. Happy to hear any alternative solution for the longer
> term if it is hard in short term.
> 
>>>> That downside is pretty much why aac4e67d6eb9 ("firmware: arm_scmi:
>>>> Always create devices for standard protocols") does things the way
>>>> it does.
>>>>
>>>> If we want something like this patch, then my suggestion would be to
>>>> make scmi_protocol_device_unrequest() skip the
>>>> blocking_notifier_call_chain(SCMI_BUS_NOTIFY_DEVICE_UNREQUEST) call
>>>> for standard protocol devices, but otherwise keep them on the request
>>>> list to keep the detection of duplicate device-ids.
>>>>
>>>
>>> Ah, is this the same reference of duplicate-ids for std-proto devices
>>> made above ?
>>
>> Yes.
>>
> 
> Thanks!
> 
>>> If so, I understand what you mean now. I agree we need
>>> to fix that too. I simply don't like keeping 2 possible paths or
>>> device creation for std proto devices as I feel it will be troublesome
>>> in the future.
>>
>> Ok, I see.
>>
>>>> But I'm not sure even that is necessary, my change deliberately only
>>>> touched the scmi_device_create(name = NULL) path to make sure
>>>> the devices are initially created. Future driver unregistering leading
>>>> to them going away as before is not really a problem IMHO.
>>>>
>>>
>>> Do you mean, you prefer to keep 2 paths for std protocol device creation ?
>>  
>> Well we've 2 different paths for non std protocol device creation too,
>> depending on if the protocol-id shows up before or after a driver
>> requesting the device arrives.
>>
> 
> Agreed, but for std protocol we are sticking with enumeration time now.
> 
>> So I'm not convinced we really need to fix anything, but if you want
>> to move to only 1 path for std protocol device creation that I've no
>> objection against that.
>>
> 
> I think you missed the fact we are supporting the 2 different drivers
> with same <proto_id, name>. You worded it differently and sorry for not
> getting that early.
> 
>> Note that other busses do accept multiple drivers claiming the same
>> device-id. With the first one to probe successfully winning. So we
>> could also proceed with that patch as is.
>>
> 
> Indeed, that is the only way it can be made work. In this case we have
> block list in scmi-pinctl driver for i.MX platform and that's how they
> have their own driver probed successfully. It was quite a ride in getting
> that merged after all attempts to have single generic driver failed 🙁.
> It is created problems as we created multiple devices sharing same
> fwnode unfortunately. This series solved the issue by trying to remove
> multiple device creation with same fwnode where possible for that reason.
> Hope that clarifies things, sorry I realise the context in the cover letter
> was bit short to give overall picture of issue and history on this.

Ack, as I said above if we want to allow multiple drivers claiming the same
device-id. Then this patch is fine as as.

With that resolved, the patch looks good to me:

Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>

Regards,

Hans

Re: [PATCH 2/4] firmware: arm_scmi: Skip requests for standard protocol devices

[Sudeep Holla]

On Sat, Oct 03, 2026 at 03:13:42PM +0200, Hans de Goede wrote:
> 
> Ack, as I said above if we want to allow multiple drivers claiming the same
> device-id. Then this patch is fine as as.
> 
> With that resolved, the patch looks good to me:
> 
> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
> 

Thanks, I may repost with no change just to see if sashiko grabs all the
patches correctly and succeeds in reviewing unlike this version.

-- 
Regards,
Sudeep

Re: [PATCH 2/4] firmware: arm_scmi: Skip requests for standard protocol devices

[Sudeep Holla]

On Fri, Oct 02, 2026 at 10:36:31AM +0100, Sudeep Holla wrote:
> The SCMI core creates devices for the standard protocol IDs during
> protocol enumeration, without waiting for an SCMI driver request.
> Recording a request for one of these devices also rejects a second
> driver registering the same protocol/name pair.
> 
> When the first driver unregisters, unrequesting that pair destroys the
> core-created device. No other driver can be bound to it at that point,
> but removing it also removes the device that a later driver could bind
> to or use for module autoloading.
> 
> Skip request tracking for standard devices. Keep request tracking and
> rollback for nonstandard devices unchanged.
> 
> Cc: Hans de Goede <johannes.goede@oss.qualcomm.com>
> Fixes: aac4e67d6eb9 ("firmware: arm_scmi: Always create devices for standard protocols")
> Reported-by: Peng Fan <peng.fan@oss.nxp.com>
> Closes: https://lore.kernel.org/all/20260928-driver-core-v1-1-0846bb8e0f32@nxp.com
> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
> ---
>  drivers/firmware/arm_scmi/bus.c | 73 +++++++++++++++++++++++------------------
>  1 file changed, 41 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
> index f2e2ed56bc32..230ee9f6f1aa 100644
> --- a/drivers/firmware/arm_scmi/bus.c
> +++ b/drivers/firmware/arm_scmi/bus.c
> @@ -186,12 +186,44 @@ static void scmi_protocol_device_unrequest(const struct scmi_device_id *id_table
>  	}
>  }
>  
> +/* Standard protocols table */
> +static const struct scmi_device_id scmi_std_id_table[] = {
> +	{ SCMI_PROTOCOL_POWER, "genpd" },
> +	{ SCMI_PROTOCOL_SYSTEM, "syspower" },
> +	{ SCMI_PROTOCOL_PERF, "perf" },
> +	{ SCMI_PROTOCOL_PERF, "cpufreq" },
> +	{ SCMI_PROTOCOL_CLOCK, "clocks" },
> +	{ SCMI_PROTOCOL_SENSOR, "hwmon" },
> +	{ SCMI_PROTOCOL_SENSOR, "iiodev" },
> +	{ SCMI_PROTOCOL_RESET, "reset" },
> +	{ SCMI_PROTOCOL_VOLTAGE, "regulator" },
> +	{ SCMI_PROTOCOL_POWERCAP, "powercap" },
> +	{ SCMI_PROTOCOL_PINCTRL, "pinctrl" },
> +	{ SCMI_PROTOCOL_PINCTRL, "pinctrl-imx" },

The above line must be deleted, I copied the array as is and forgot to
drop this.

-- 
Regards,
Sudeep

[PATCH 3/4] pinctrl: imx: Match the standard SCMI pinctrl device

[Sudeep Holla]

Use the standard "pinctrl" SCMI device name instead of the i.MX-specific
"pinctrl-imx" name. Standard devices no longer have exclusive request
tracking, so the i.MX and generic pinctrl drivers can register for the
same protocol/name pair. Their probe checks select the appropriate
driver for the platform.

This solves the issue that occurs when both "pinmux" and "pinmux-imx"
devices that share the same fwnode as only the first device registered
is assigned as the owner of the fwnode. If this owner device fails to
probe (e.g., its driver is blocklisted or missing), it never reaches
the driver_bound() stage and the system skips cleaning up its supplier
links. Even if a alternative device binds successfully, the system
still looks to the broken original owner. As a result, all dependent
hardware components (I2C, SPI, UART, USB, MMC, PCIe) defer probing
forever, halting the boot process.

Note that the solution doesn't support same fwnode being shared by
multiple devices and associated fw_devlink feature.

Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: NXP S32 Linux Team <s32@nxp.com>
Cc: Linus Walleij <linusw@kernel.org>
Cc: linux-gpio@vger.kernel.org
Cc: imx@lists.linux.dev
Reported-by: Peng Fan <peng.fan@oss.nxp.com>
Closes: https://lore.kernel.org/all/20260928-driver-core-v1-1-0846bb8e0f32@nxp.com
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
 drivers/pinctrl/freescale/pinctrl-imx-scmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/freescale/pinctrl-imx-scmi.c b/drivers/pinctrl/freescale/pinctrl-imx-scmi.c
index 613552e35070..b259a526ccc1 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx-scmi.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx-scmi.c
@@ -354,7 +354,7 @@ static int scmi_pinctrl_imx_probe(struct scmi_device *sdev)
 }
 
 static const struct scmi_device_id scmi_id_table[] = {
-	{ SCMI_PROTOCOL_PINCTRL, "pinctrl-imx" },
+	{ SCMI_PROTOCOL_PINCTRL, "pinctrl" },
 	{ }
 };
 MODULE_DEVICE_TABLE(scmi, scmi_id_table);

-- 
2.43.0

Re: [PATCH 3/4] pinctrl: imx: Match the standard SCMI pinctrl device

[Peng Fan]

On Fri, Oct 02, 2026 at 10:36:32AM +0100, Sudeep Holla wrote:
>Use the standard "pinctrl" SCMI device name instead of the i.MX-specific
>"pinctrl-imx" name. Standard devices no longer have exclusive request
>tracking, so the i.MX and generic pinctrl drivers can register for the
>same protocol/name pair. Their probe checks select the appropriate
>driver for the platform.
>
>This solves the issue that occurs when both "pinmux" and "pinmux-imx"
>devices that share the same fwnode as only the first device registered
>is assigned as the owner of the fwnode. If this owner device fails to
>probe (e.g., its driver is blocklisted or missing), it never reaches
>the driver_bound() stage and the system skips cleaning up its supplier
>links. Even if a alternative device binds successfully, the system
>still looks to the broken original owner. As a result, all dependent
>hardware components (I2C, SPI, UART, USB, MMC, PCIe) defer probing
>forever, halting the boot process.
>
>Note that the solution doesn't support same fwnode being shared by
>multiple devices and associated fw_devlink feature.
>
>Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
>Cc: NXP S32 Linux Team <s32@nxp.com>
>Cc: Linus Walleij <linusw@kernel.org>
>Cc: linux-gpio@vger.kernel.org
>Cc: imx@lists.linux.dev
>Reported-by: Peng Fan <peng.fan@oss.nxp.com>
>Closes: https://lore.kernel.org/all/20260928-driver-core-v1-1-0846bb8e0f32@nxp.com
>Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>

Reviewed-by: Peng Fan <peng.fan@nxp.com>

Re: [PATCH 3/4] pinctrl: imx: Match the standard SCMI pinctrl device

[Linus Walleij]

On Fri, Oct 2, 2026 at 11:37 AM Sudeep Holla <sudeep.holla@kernel.org> wrote:

> Use the standard "pinctrl" SCMI device name instead of the i.MX-specific
> "pinctrl-imx" name. Standard devices no longer have exclusive request
> tracking, so the i.MX and generic pinctrl drivers can register for the
> same protocol/name pair. Their probe checks select the appropriate
> driver for the platform.
>
> This solves the issue that occurs when both "pinmux" and "pinmux-imx"
> devices that share the same fwnode as only the first device registered
> is assigned as the owner of the fwnode. If this owner device fails to
> probe (e.g., its driver is blocklisted or missing), it never reaches
> the driver_bound() stage and the system skips cleaning up its supplier
> links. Even if a alternative device binds successfully, the system
> still looks to the broken original owner. As a result, all dependent
> hardware components (I2C, SPI, UART, USB, MMC, PCIe) defer probing
> forever, halting the boot process.
>
> Note that the solution doesn't support same fwnode being shared by
> multiple devices and associated fw_devlink feature.
>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: NXP S32 Linux Team <s32@nxp.com>
> Cc: Linus Walleij <linusw@kernel.org>
> Cc: linux-gpio@vger.kernel.org
> Cc: imx@lists.linux.dev
> Reported-by: Peng Fan <peng.fan@oss.nxp.com>
> Closes: https://lore.kernel.org/all/20260928-driver-core-v1-1-0846bb8e0f32@nxp.com
> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>

Acked-by: Linus Walleij <linusw@kernel.org>

I guess it needs to go in with the rest of the patches to firmware?

Else tell me and I'll just apply it.

Yours,
Linus Walleij

Re: [PATCH 3/4] pinctrl: imx: Match the standard SCMI pinctrl device

[Sudeep Holla]

On Wed, Oct 07, 2026 at 12:32:12PM +0200, Linus Walleij wrote:
> On Fri, Oct 2, 2026 at 11:37 AM Sudeep Holla <sudeep.holla@kernel.org> wrote:
> 
> > Use the standard "pinctrl" SCMI device name instead of the i.MX-specific
> > "pinctrl-imx" name. Standard devices no longer have exclusive request
> > tracking, so the i.MX and generic pinctrl drivers can register for the
> > same protocol/name pair. Their probe checks select the appropriate
> > driver for the platform.
> >
> > This solves the issue that occurs when both "pinmux" and "pinmux-imx"
> > devices that share the same fwnode as only the first device registered
> > is assigned as the owner of the fwnode. If this owner device fails to
> > probe (e.g., its driver is blocklisted or missing), it never reaches
> > the driver_bound() stage and the system skips cleaning up its supplier
> > links. Even if a alternative device binds successfully, the system
> > still looks to the broken original owner. As a result, all dependent
> > hardware components (I2C, SPI, UART, USB, MMC, PCIe) defer probing
> > forever, halting the boot process.
> >
> > Note that the solution doesn't support same fwnode being shared by
> > multiple devices and associated fw_devlink feature.
> >
> > Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> > Cc: NXP S32 Linux Team <s32@nxp.com>
> > Cc: Linus Walleij <linusw@kernel.org>
> > Cc: linux-gpio@vger.kernel.org
> > Cc: imx@lists.linux.dev
> > Reported-by: Peng Fan <peng.fan@oss.nxp.com>
> > Closes: https://lore.kernel.org/all/20260928-driver-core-v1-1-0846bb8e0f32@nxp.com
> > Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
> 
> Acked-by: Linus Walleij <linusw@kernel.org>
> 

Thanks!

> I guess it needs to go in with the rest of the patches to firmware?
> 
> Else tell me and I'll just apply it.

Yes for the functionality to work, it needs to be part of the series.

-- 
Regards,
Sudeep

[PATCH 4/4] firmware: arm_scmi: Skip unused performance-domain devices

[Sudeep Holla]

The SCMI performance-domain driver uses the named "perf" device only
when its firmware node declares #power-domain-cells. Otherwise its
probe returns without registering a provider, while the same SCMI
protocol may still be needed by the separate "cpufreq" device.

Do not create the "perf" device when the provider property is absent.
This avoids an unnecessary device claiming the protocol fwnode and
leaves cpufreq creation unchanged. Update the device-creation contract
to document that an intentionally omitted named device returns NULL.

Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
 drivers/firmware/arm_scmi/bus.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index 230ee9f6f1aa..9a9a816eb119 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -571,6 +571,11 @@ _scmi_device_create(struct fwnode_handle *fwnode, struct device *parent,
 {
 	struct scmi_device *sdev;
 
+	/* The perf device is only needed when it provides power domains. */
+	if (protocol == SCMI_PROTOCOL_PERF && !strcmp(name, "perf") &&
+	    !fwnode_property_present(fwnode, "#power-domain-cells"))
+		return NULL;
+
 	sdev = __scmi_device_create(fwnode, parent, protocol, name);
 	if (!sdev)
 		pr_err("(%pfwf) Failed to create device - protocol 0x%x (%s)\n",
@@ -597,10 +602,8 @@ _scmi_device_create(struct fwnode_handle *fwnode, struct device *parent,
  *
  * Return: The created device (or one of them if @name was NOT provided and
  *	   multiple devices were created) or NULL if no device was created;
- *	   note that NULL indicates an error ONLY in case a specific @name
- *	   was provided: when @name param was not provided, a number of devices
- *	   could have been potentially created for a whole protocol, unless no
- *	   device was found to have been requested for that specific protocol.
+ *	   note that NULL can also indicate that a named device is not needed
+ *	   for this fwnode, or that no device was requested when @name is NULL.
  */
 struct scmi_device *scmi_device_create(struct fwnode_handle *fwnode,
 				       struct device *parent, int protocol,

-- 
2.43.0

Re: [PATCH 4/4] firmware: arm_scmi: Skip unused performance-domain devices

[Hans de Goede]

Hi,

On 2-Oct-26 11:36, Sudeep Holla wrote:
> The SCMI performance-domain driver uses the named "perf" device only
> when its firmware node declares #power-domain-cells. Otherwise its
> probe returns without registering a provider, while the same SCMI
> protocol may still be needed by the separate "cpufreq" device.
> 
> Do not create the "perf" device when the provider property is absent.
> This avoids an unnecessary device claiming the protocol fwnode and
> leaves cpufreq creation unchanged. Update the device-creation contract
> to document that an intentionally omitted named device returns NULL.
> 
> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>

Regards,

Hans



> ---
>  drivers/firmware/arm_scmi/bus.c | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
> index 230ee9f6f1aa..9a9a816eb119 100644
> --- a/drivers/firmware/arm_scmi/bus.c
> +++ b/drivers/firmware/arm_scmi/bus.c
> @@ -571,6 +571,11 @@ _scmi_device_create(struct fwnode_handle *fwnode, struct device *parent,
>  {
>  	struct scmi_device *sdev;
>  
> +	/* The perf device is only needed when it provides power domains. */
> +	if (protocol == SCMI_PROTOCOL_PERF && !strcmp(name, "perf") &&
> +	    !fwnode_property_present(fwnode, "#power-domain-cells"))
> +		return NULL;
> +
>  	sdev = __scmi_device_create(fwnode, parent, protocol, name);
>  	if (!sdev)
>  		pr_err("(%pfwf) Failed to create device - protocol 0x%x (%s)\n",
> @@ -597,10 +602,8 @@ _scmi_device_create(struct fwnode_handle *fwnode, struct device *parent,
>   *
>   * Return: The created device (or one of them if @name was NOT provided and
>   *	   multiple devices were created) or NULL if no device was created;
> - *	   note that NULL indicates an error ONLY in case a specific @name
> - *	   was provided: when @name param was not provided, a number of devices
> - *	   could have been potentially created for a whole protocol, unless no
> - *	   device was found to have been requested for that specific protocol.
> + *	   note that NULL can also indicate that a named device is not needed
> + *	   for this fwnode, or that no device was requested when @name is NULL.
>   */
>  struct scmi_device *scmi_device_create(struct fwnode_handle *fwnode,
>  				       struct device *parent, int protocol,
> 

Re: [PATCH 0/4] firmware: arm_scmi: Some fixes to address conflicts with fw_devlink

[Peng Fan]

On Fri, Oct 02, 2026 at 10:36:29AM +0100, Sudeep Holla wrote:
>Peng’s [1] identified the problem of multiple SCMI devices sharing one
>protocol fwnode. His [2] shows the consequence: the first device owns
>the fwnode but does not bind, so fw_devlink can leave consumers deferred
>even when another device binds successfully.
>
>This four-patch series reduces those cases within SCMI. It prevents
>protocol device creation in exclusive raw mode, stops treating core
>created standard devices as driver owned requests, and makes the i.MX
>pinctrl driver match the standard `pinctrl` device instead of creating
>a second device for the same fwnode. It also omits the `perf` device
>when the firmware node does not describe a performance domain provider,
>without changing `cpufreq` device creation. IIO/HWMON don't have any
>fw_devlink dependency and having two devices shouldn't be an issue.
>
>These changes address the SCMI cases above; they do not provide a
>general driver core solution for devices that share a fwnode.
>
>Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
>
>[1] https://lore.kernel.org/all/20250120-scmi-fwdevlink-v2-0-3af2fa37dbac@nxp.com
>[2] https://lore.kernel.org/all/20260928-driver-core-v1-1-0846bb8e0f32@nxp.com
>
>---
>Sudeep Holla (4):
>      firmware: arm_scmi: Avoid protocol devices in exclusive raw mode
>      firmware: arm_scmi: Skip requests for standard protocol devices
>      pinctrl: imx: Match the standard SCMI pinctrl device
>      firmware: arm_scmi: Skip unused performance-domain devices
>

Tested-by: Peng Fan <peng.fan@nxp.com> #i.MX95 EVK

Thanks
Peng