enhancing module info to allow grouping of firmwares

[Alex Deucher]

On Wed, Mar 15, 2023 at 4:35 PM Dave Airlie <airlied at 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.

What about bundling the compatible FWs together into one big FW
package and tag it with some sort of common metadata header that the
driver can parse.  That would keep all cross FW compatibilities
together.  Then on the driver side, change the firmware name specified
in the kernel to match whatever is required for that kernel version.
E.g., one kernel could specify nv_fw_1_0.bin and another could specify
nv_fw_2_1.bin, etc.  It's pretty ugly and not a great user experience
if there is no backwards compat, but it should work as only the
compatible FW would be copied to the initrd.

Alex


>
> Thanks,
> Dave.