Re: [PATCH] driver core: hand off fwnode ownership when shared fwnode owner is rejected

[Sudeep Holla <sudeep.holla@kernel.org>]

On Mon, Sep 28, 2026 at 07:49:01PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
> 
> When multiple devices share the same fwnode (e.g. the SCMI bus creates
> both "pinctrl" and "pinctrl-imx" devices for SCMI_PROTOCOL_PINCTRL), only
> the first device registered becomes the fwnode owner (fwnode->dev, set in

This has been rejected in the past. Apart from the trigger in -next,
anything else has changed ?

> device_add()). If that owner never binds -- for example its driver returns
> -ENODEV because it is blocklisted on this SoC, or because its driver is
> not compiled in at all -- then driver_bound() is never called for it, so
> fwnode_links_purge_suppliers() and fw_devlink_pickup_dangling_consumers()
> are never run for the fwnode. The child fwnode supplier links (pin group
> nodes such as lpi2c3grp, uart5grp, ...) stay unsatisfied and every
> consumer of those child nodes defers probe forever.
> 
> On i.MX95 this manifests as a complete boot failure: the generic "pinctrl"
> SCMI device claims fwnode ownership but its driver returns -ENODEV, while
> the vendor "pinctrl-imx" device binds successfully. Because
> dev->fwnode->dev still points at the rejected "pinctrl" device,
> driver_bound() of "pinctrl-imx" skips the supplier purge and dangling
> consumer pickup, so all I2C buses, SPI, UART, MMC, USB and PCIe
> controllers wait forever for their pinctrl suppliers.
> 
> Fix this in two places:
> 
> 1. In really_probe() failure path: when the driver definitively rejects
>    a device (-ENODEV / -ENXIO), fw_devlink_release_shared_fwnode() is
>    called. If the rejected device is the fwnode owner, it either
>    transfers ownership to an already-bound sibling (and runs the
>    purge/pickup on its behalf) or clears ownership so the next sibling
>    to bind can re-acquire it.
> 
> 2. In device_links_driver_bound(): re-acquire the fwnode when it is
>    unowned (!fwnode->dev) or when the current owner has no driver at
>    all (!fwnode->dev->driver, meaning the driver was never compiled in
>    or loaded as a module). This covers the case where probe rejection
>    never happens because no driver ever matches.
> 
> fwnode->dev is not serialized by a lock; instead every writer only ever
> touches a fwnode->dev it already owns (== dev, as device_del() does when
> it clears ownership) or one that is currently unowned (== NULL, as
> device_add() does when it claims ownership). This patch follows the same
> discipline: fw_devlink_release_shared_fwnode() only writes fwnode->dev
> when this device is the current owner; device_links_driver_bound() only
> claims fwnode->dev when it is NULL or when the current owner has no
> driver (and therefore cannot be in the process of binding).
> 
> Fixes: f9aa460672c9 ("driver core: Refactor fw_devlink feature")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> This issue is triggered by 
> aac4e67d6eb9 ("firmware: arm_scmi: Always create devices for standard protocols")
> in linux-next next-20260925.
> 
> But I think this is a fix to
> f9aa460672c9 ("driver core: Refactor fw_devlink feature")
> 

Does dropping i.MX specials from list of devices solves the problem ?
I am more than happy to drop i.MX special in the code and let you
sort the pinmux mess you guys have created.

And also I remember you creating situation disabling cpufreq in the cmdline.
Will that be ever used on those i.MX platforms ?

I am not against the patch if others are OK.

-- 
Regards,
Sudeep