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

[Sudeep Holla]

On Tue, Sep 29, 2026 at 09:47:42AM +0800, Peng Fan wrote:
> Hi Sudeep,
> 
> On Mon, Sep 28, 2026 at 01:09:08PM +0100, Sudeep Holla wrote:
> >On Mon, Sep 28, 2026 at 07:49:01PM +0800, Peng Fan (OSS) wrote:
> >> From: Peng Fan <peng.fan@xxxxxxx>
> >> 
> >> 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 ?
> 
> When both pinctrl-scmi.c and pinctrl-imx-scmi.c are built into the
> kernel Image, both drivers call module_scmi_driver() at init time, which
> goes through:
>   scmi_driver_register()
>     → scmi_protocol_table_register(id_table)
>       → scmi_protocol_device_request()
>         → scmi_device_request_notifier()
>           → scmi_create_protocol_devices(fwnode, ..., "pinctrl-imx")
> So the on-demand path already creates both "pinctrl" and "pinctrl-imx"

Yes, but this particular device is i.MX specific issue as it should
have never been there. So I will discard that in any future discussion.
Use the SCMI pinmux driver and get rid of SCMI pinctrl-imx.

> devices for protocol@19, sharing the same fwnode, regardless of
> scmi_std_id_table. aac4e67d6eb9 just added a second path that does
> the same thing earlier - the fundamental problem existed before it.
> 
> This issue has been here for 2 years.

Thanks for clarifying this. You initial email seem to directly blame
the commit in -next. Please don't bring that commit into discussion then.
It was completely misleading.

> I proposed a patch in scmi side [1][2], but never made into mainline.
> [1] https://lore.kernel.org/all/CAGETcx87Stfkru9gJrc1sf=PtFGLY7=jrfFaCzK5Z4hq+2TCzg@xxxxxxxxxxxxxx/
> [2] https://lore.kernel.org/arm-scmi/ZryUgTOVr_haiHuh@pluto/
> 
> The issue is not specific to pinctrl w/o imx.
> 

Agreed. Perf/cpufreq is another possible issue you have brought up IIRC.
Since cpufreq must not have dependency like pinmux, we should be able to solve
it in some other way.

> The problem is that two devices share one fwnode, the first one registered
> claims fwnode->dev, and if it never binds, driver_bound() of the second
> device skips the dangling consumer pickup because fwnode->dev != dev.
> 

Agreed, but it shouldn't be the normal case unless there is a strong need
and there is the dependency you mention or you mess up by creating duplicate
devices like pinmux-imx. That's you own doing, sorry.


[...]

> >
> >Does dropping i.MX specials from list of devices solves the problem ?
> 
> No - dropping "pinctrl-imx" from scmi_std_id_table would not fix it
> when both drivers are built-in, because scmi_protocol_device_request()
> from the driver registration path still creates both devices.
> 

OK, thanks for the confirmation.

> >I am more than happy to drop i.MX special in the code and let you
> >sort the pinmux mess you guys have created.
> 
> I understand the concern about platform-specific code in the standard
> table. But the issue is not specific to pinctrl-imx - it is a generic
> fw_devlink gap that affects any bus creating multiple devices per fwnode.
> The same structural pattern exists for SCMI_PROTOCOL_PERF ("perf" +
> "cpufreq") and SCMI_PROTOCOL_SENSOR ("hwmon" + "iiodev").
> 

Yes perf/cpufreq case I recall and we should be able to work out something.
Sensor has no dependency like pinmux and shouldn't be a problem. Have you
faced real issue with it ?

> Cristian also shared his insights before, in [3].
> 
> "
> ....while other drivers exists that share the usage of the same protocol
> (HWMON/IIO GENPD/CPUFREQ), they use the same protocol to achieve different
> things in different subsytems...and they are anyway impacted (even to a less
> degree) by this fw_devlink issue AFAIU so the problem indeed exist also
> out of pinctrl-imx
> "
> 
> [3] https://lore.kernel.org/all/Z65U2SMwSiOFYC0v@pluto/
> 

I agree and that's what I mean above.

> >
> >And also I remember you creating situation disabling cpufreq in the cmdline.
> >Will that be ever used on those i.MX platforms ?
> 
> For the PERF pair, both drivers bind successfully today so there is no
> issue in practice. But if "perf" (the fwnode owner) fails probe while
> "cpufreq" binds, the same fwnode ownership deadlock occurs. This is not
> about disabling cpufreq - it is about the owner device failing to bind
> for any reason.
> 

Thanks for the explanation.

> >
> >I am not against the patch if others are OK.
> 
> Thanks. The patch fixes a generic fw_devlink gap in driver_bound()
> where a device binding successfully on a shared fwnode cannot resolve
> dangling consumers of child fwnodes because it is not the fwnode owner.
> The fix follows the existing fwnode->dev ownership discipline (only
> writing fwnode->dev when it is NULL, owned by self, or owned by a
> driverless device) and handles all three scenarios:
> 1. Owner probe rejected (-ENODEV/-ENXIO) - owner hands off in
> really_probe() failure path
> 2. Owner rejected earlier, fwnode now unowned - sibling re-acquires
> in driver_bound()
> 3. Owner's driver never compiled/loaded - sibling takes over from
> driverless owner in driver_bound()
> 
> 
> If driver core maintainers have better solution for the case that
> multiple devices share one fwnode, I would appreciate.
> 

IIRC, they don't want to use 2 device pointing to same fwnode.

-- 
Regards,
Sudeep