[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 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 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

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