Re: [PATCH v2 0/2] firmware: arm_scmi: Ensure automatic module loading

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

On Thu, Jul 09, 2026 at 04:49:18PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 9-Jul-26 16:37, Sudeep Holla wrote:
> > On Thu, Jul 09, 2026 at 04:31:00PM +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 9-Jul-26 16:21, Sudeep Holla wrote:
> > [...]
> >>>
> >>> I need to recall why we moved from static list of devices to dynamic.
> >>> One reason I can think right now is the vendor protocols and their drivers
> >>> But in general it was an attempt to help multiple drivers bind to different
> >>> scmi_devices that have same protocol ID. E.g. the performance protocol
> >>> can be used by cpufreq and devfreq/performance genpd drivers.
> >>
> >> Note it is ok to have multiple drivers bind to the same modalias,
> >> depending on the reason why there are multiple drivers either one
> >> should detect that it is not compatible and exit probe() with -ENODEV
> >> or there should be some other mechanism to make sure only one driver
> >> loads.
> >>
> >> E.g. duplicate USB device-ids happen (they shouldn't but they do) and
> >> then the drivers typically figure out if they are talking to the device
> >> which they were written for, or the other device with the same USB-ids
> >> and then one of the 2 drivers exits with -ENODEV.
> >>
> > 
> > Understood. Sorry I tried to explain with examples assuming you may not
> > be aware of the details, but now reading your response, you have better
> > examples.
> > 
> >>>> I wonder if we can just move a small part of the drivers
> >>>> (some mapping table) into the bus code and then just have this work as it
> >>>> does on regular busses. I hope to be able to make some time to look into
> >>>> this soonish.
> >>>>
> >>>
> >>> I started with that few years ago and we then moved to this dynamic
> >>> device creation. But I agree if it is deviation from the norms(which I
> >>> wasn't aware of at the time), we can remove it.
> >>
> >> Looking at the issue this is causing for automatic module loading if we
> >> can get back to the bus enumeration code always creating a device without
> >> waiting for the driver kmod to load then that would be good IMHO.
> >>
> > 
> > Sure if it fixes the issue for you. Cristian can point out anything I
> > might have missed to consider as he is the one who reworked it and made
> > it dynamic device creation which at the time sounded nice option to
> > solve the issue. We weren't aware that it could cause such issues 🙁.
> 
> Note that before patch 1/2 of this series we did not have working
> module-autoloading for SCMI modules at all. With that said yes it would
> be nice to get this working.
> 
> Can you provide a patch for this to try ?
> 

Not sure what exactly are you asking, but I don't have anything w.r.t
the discussion handy to share. The codebase has moved a lot to revert
just the dynamic creation addition patch unfortunately.

-- 
Regards,
Sudeep