[PATCH 3/3] firmware: arm_scmi: Emit modalias for SCMI devices

[Cristian Marussi]

On Fri, Jan 31, 2025 at 02:18:22PM +0000, Sudeep Holla wrote:
> In order to enable libkmod lookups for SCMI device objects to their
> corresponding module, add 'modalias' to the base attribute of SCMI
> devices.
> 

Hi Sudeep,

Indeed, as of today if you build the SCMI stack completely as modules, only the
core stack (scmi-core/scmi-module) and the needed SCMI transports are loaded
automatically, so this patch, I understand, is meant to add the missing bits
to enable autoloading also for the SCMI drivers that sits on top like
scmi-cpufreq etc..

In fact, I tried experimenting with something similar to your solution
recently to enable MODALIAS emission and full stack autoloading, BUT then
I realized it could have worked ONLY with an additional hack...

...the problem lays in the fact that since we wanted to allow Vendor
drivers and protocols to be easily added without changing the core (as
asked by vendors themslves AFAICR), we dont have a central static
devices-table hold by the SCMI bus core (as usual) but instead we let
SCMI drivers dynamically request protocol/devices that are needed...

...and this in turn means that the devices are created only when a driver
requires a specifc protocol/name pair (and a matching DT entry is found)
during its initalization at load time...so it's a chicken-egg problem
since the MODALIAS that will cause, say, scmi-cpufreq to be loaded will
be emitted only when the device for scmi-cpufeq will be created BUT that
currently happens only if the device was requested during the init/loading
of scmi-cpufreq itself...

...the dynamic request-device mechanism added to give vendors flexibility
does break the usual module autoloading capabilities AFAIU...

...indeed I tested this series with a full modularized SCMI stack and it
does NOT cause the full stack to be loaded...

Having said that, since this dynamic-request device mechanism was meant
to ease vendors additions, my hack was simply to pre-request all the
standard protocol devices at bus init...in that way the full stack does
finally autoload...I will post that 2 patches of mine as and RFC in
response to this for the sake of clarity...

Note that such a hack, or a better polished version of it, would NOT work
anyway for Vendor modules: if we want to keep such flexibility they still
have to be loaded manually...

Alternatively we could get rid of dynamic device creation as a whole and
revert to a more standard static central devicetable for all...not sure
really if the flexibility of device creation at runtime without keeping
a common central table is really needed/appreciated by the Vendors that
asked for it in first place :D

Thanks,
Cristian