Re: [RFC PATCH 2/2] firmware: arm_scmi: Add bus support for autoloading

Hi All,

On 29-Jul-26 16:17, Sudeep Holla wrote:
> On Wed, Jul 29, 2026 at 04:11:18PM +0200, Daniel Lezcano wrote:
>>
>> Hi Cristian,
>>
>> On 6/9/26 11:01, Sudeep Holla wrote:
>>> On Mon, Jun 08, 2026 at 05:51:57PM +0100, Cristian Marussi wrote:
>>
>> [ ... ]
>>
>>>> Thoughts ? Plans ?

Given the internal discussion about this on Slack I decided to
look into fixing this and while reading the thread from [1]
found a pointer to this thread.

>>> Just repost as non-rfc after next merge window and we will see if there is
>>> much interest to get it merged for the following one and take it from there.
>>
>> Are you planning to resend the series ? I can test them on my laptop
>>
> 
> I thought [1] from Bjorn was addressing the same issue ?

Yes, but it does not solve the chicken and the egg problem we've wrt
module auto-loading. It tries to do so in patch 2/2 of the [1] series
but that relies on request_module() rather then a proper/normal
modalias uevent and that request_module() typically will happen
inside the initramfs and then fails if the needed module is not in
the initramfs.

Normal bus devices with a proper modalias uevent do not suffer from
this because there udev does the modprobe based on the uevent file
under the device's sysfs dir and it retries this after the switch
to the real rootfs.

The problem the current scmi code has is that it creates
devices under the SCMI bus based on protocol+name pairs in
the scmi_requested_devices list.

And that list is populated based on driver->id_table entries
from any loaded drivers. So for a device to get created
the module registering the driver with the matching
scmi_device_id-s needs to be loaded first.

And the way the device model + udev contract works is that
the module will be auto-loaded based on the modalias of
the created device.

So no module, no device on the scmi bus and no device no
module autoloading. Hence chicken and egg.

I believe that the first patch from Bjorn's series which
is similar but more complete then the first patch from
this (Cristian's) series + pre-populating
the scmi_requested_devices for Standard protocol devices
as Christian's second patch does should do the trick.

This break the chicken and egg problem for standard proto
devices. This means no auto-loading for modules for
custom protocols, there is no way to avoid this.

As an exception we could add any custom protocols for
which support is added to the mainline kernel to
the table used to pre-populate the scmi_requested_devices
list.

I'll go and prepare a new series consisting of Bjorn's 1/2
(unmodified) + Christian's 2/2 reduced to just pre-populating
the table and after testing that that does the trick I'll
post that as a v2 series obsoleting both existing series.

Regards,

Hans


[1] https://lore.kernel.org/all/[email protected]