On Tue, Jul 18, 2023 at 5:41 AM Lucas De Marchi <lucas.demarchi@xxxxxxxxx> wrote: > > On Fri, Jul 07, 2023 at 11:41:48AM -0700, Luis Chamberlain wrote: > >On Tue, Jul 04, 2023 at 12:50:50PM +1000, Dave Airlie wrote: > >> From: Dave Airlie <airlied@xxxxxxxxxx> > >> > >> This adds two tags that will go into the module info. > >> > >> The first denotes a group of firmwares, when that tag is present all > >> MODULE_FIRMWARE lines between the tags will be ignored by new versions of > >> dracut. > >> > >> The second makes an explicitly ordered group of firmwares to search for > >> inside a group setting. New dracut will pick the first available firmware > >> from this to put in the initramfs. > >> > >> Old dracut will just ignore these tags and fallback to installing all > >> the firmwares. > >> > >> The corresponding dracut code it at: > >> https://github.com/dracutdevs/dracut/pull/2309 > >> > >> Cc: Luis Chamberlain <mcgrof@xxxxxxxxxx> > >> Cc: linux-modules@xxxxxxxxxxxxxxx > >> Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx > >> Signed-off-by: Dave Airlie <airlied@xxxxxxxxxx> > > > >Lucas, did this end up working for you as well? > > I didn't try this yet, no. My opinion is similar to the first version of > this series: this is the first case in which we are making the order of > 2 different keys to be relevant and it doesn't look so pretty. It may > also be hard to adapt some of the drivers like i915 to intertwine the 2 > modinfo keys. This doesn't have as much reliance on order, it just relies on the group tags not being reordered outside the modinfos between them. > > However, the alternative I provided also has some flaws, so I said I'd > be ok continuing in this direction. Humn... how about merging part of my > suggestion to mitigate the duplication we have now? > > - Document that when using a fw group, it's expected userspace > will consider higher versions within a group to have higher > prio and add only one of them. Thinking on a distro packaging, > it could be extended to packaging fewer blobs too. > > If we agree on "firmware files within a group are version-sorted", then > we don't need the extra MODULE_FIRMWARE_GROUP_LIST, do we? But what is the versioning to be used, I have to be very careful to have this be backwards compat, and not suddenly stop pulling in some versions of a fw because they happen to have used a version scheme that this tramples. If you are saying, we need to define a firmware versioning rule, then that's a big task and would involve changing a bunch of things in the fw and drivers. i915: adlp_dmc_ver2_14.bin.xz dg2_guc_70.1.2.bin.xz mtl_guc_70.bin.xz amdgpu: polaris11_mec.bin.xz polaris11_mec2.bin.xz polaris11_mec_2.bin.xz polaris11_mec2_2.bin.xz I don't see what is a version field I can sort on reliably here. Now maybe I could introduce a new field Do you think we should just add explicit ordering to each module group?, so we create a MODULE_FIRMWARE_GROUP_VERSIONED("nvidia/ga106/gsp/gsp-5258902.bin", 1); MODULE_FIRMWARE_GROUP_VERSIONED("nvidia/ga106/gsp/gsp-5303002.bin", 2); and I just output group brackets + that? and fix dracut to deal with it? Dave.
