[PATCH 2/2] modules/firmware: add a new option to denote a firmware group to choose one.

Lucas De Marchi lucas.demarchi at intel.com
Mon Jul 17 19:41:39 UTC 2023


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 at redhat.com>
>>
>> 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 at kernel.org>
>> Cc: linux-modules at vger.kernel.org
>> Cc: dri-devel at lists.freedesktop.org
>> Signed-off-by: Dave Airlie <airlied at redhat.com>
>
>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.

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?

Nit: referencing dracut implementation IMO is ok, but on kernel-doc
parts we should prefer something more generic since dracut is far from
the only initrd generator nowadays.

thanks
Lucas De Marchi

>
>  Luis


More information about the dri-devel mailing list