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

[Sudeep Holla]

On Thu, Jul 09, 2026 at 04:07:17PM +0200, Hans de Goede wrote:
> Hi Brian,
> 
> On 9-Jul-26 15:28, Brian Masney wrote:
> > Hi Hans,
> > 
> > On Thu, Jul 09, 2026 at 03:22:29PM +0200, Hans de Goede wrote:
> >> On 9-Jul-26 12:10, Sudeep Holla wrote:
> >>> On Thu, Jun 18, 2026 at 10:31:12PM +0200, Hans de Goede wrote:
> >>>> On 18-Jun-26 17:56, Bjorn Andersson wrote:
> >>>>> SCMI drivers such as the Arm SCMI CPUfreq driver are allowed to built as
> >>>>> modules, but they are then not automatically loaded. Rework the SCMI
> >>>>> device table alias support to make modpost consume the information from
> >>>>> MODULE_DEVICE_TABLE(scmi, ...) and allow drivers to be loaded based on
> >>>>> this information, if known. Also add a protocol-based alias to also
> >>>>> trigger driver loading when only the SCMI protocol id is known.
> >>>>>
> >>>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxxxxxxxx>
> >>>>
> >>>> So I just gave this a test spin and unfortunately it does not work.
> >>>>
> >>>> The problem with Fedora's kernel-config / setup is that the
> >>>> request_module() from patch 2/2 runs from the initramfs, but
> >>>> the scmi_cpufreq module is only available in the rootfs.
> >>>>
> >>>> It does work if I explictly add the scmi_cpufreq module to
> >>>> the initramfs, then it does get autoloaded.
> >>>>
> >>>> We really need some place to put a uevent sysfs attr which then
> >>>> gets replayed when udev is restarted from the rootfs and then
> >>>> re-reads all the uevent files as part of its coldplug
> >>>> enumeration.
> >>>>
> >>>
> >>> I don't have much knowledge on uevent to provide any suggestions/help.
> >>> But isn't this a generic requirement ? I mean you could have modules
> >>> install on the rootfs and not all of them are packed in initramfs ?
> >>> Just wondering if that works for other modules, we can examine how
> >>> do they work and what are we missing ?
> >>
> >> scmi is special because the actual devices under /sys/bus/scmi/devices
> >> only get created when the module with the driver is loaded because
> >> of some funtion/id mapping requiring info from the driver.
> >>
> >> Patch 2/2 tries to work around this by loading all scmi drivers matching
> >> the scmi protocol which is known at bus enumeration time, but this only
> >> works if the actual scmi driver is in the initramfs because this done
> >> through directly calling modprobe() from the kernel which does not
> >> get "replayed" when switching to the real rootfs.
> > 
> > Should the SCMI drivers be added to the dracut module here?
> > 
> > https://github.com/dracut-ng/dracut/blob/main/modules.d/70kernel-modules/module-setup.sh#L73
> > 
> > A few years ago we had to add the interconnect drivers to the list for
> > Fedora.
> 
> That would be one solution. I first want to understand the problem better
> though. The scmi bus not creating the devices until the kmod with the driver
> has loaded is weird.

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.

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

-- 
Regards,
Sudeep