Re: enhancing module info to allow grouping of firmwares

[Rob Clark <robdclark@gmail.com>]

On Wed, Mar 15, 2023 at 1:35 PM Dave Airlie <airlied@gmail.com> wrote:
>
> Hey moduly/firmware people,
>
> We are facing a problem in the future of NVIDIA providing giant
> firmwares for their devices that are version locked with unstable
> APIs. Even if they weren't version locked we'd likely have to support
> multiple major versions over time.
>
> Now this becomes a problem because when you generate multiple
> initramfs and stick them into /boot over time the number of firmwares
> MODULE_FIRMWARE will match will increase and dracut will shove them
> all into the initramfs.
>
> I think one way to mitigate that would be to provide some sort of
> grouping of module firmwares that are acceptable, and having dracut
> only pick one from the list to provide in the initramfs (hopefully the
> latest one). That way the driver can provide a list of MODULE_FIRMWARE
> lines and userspace knows they are a group.
>
> I've just little idea how we could expose this via current module
> info, happy to try and come up with an enhanced scheme maybe with a
> fallback to just include all of them but was just wanting to get some
> feedback on whether this was something that anyone has ever considered
> before now.

We have a kind of similar problem with drm/msm and various other SoC
drivers that need fw which is signed with a device or vendor specific
tree.  We've partially solved that with using firmware-name from
devicetree to specify the correct device specific fw needs to be
loaded (ie. something like "qcom/LENOVO/81JL/qcdxkmsuc850.mbn") but
I've no idea how dracut should figure out what fw files should end up
in an initrd

BR,
-R