Re: [PATCH] media: venus: declare firmware files via MODULE_FIRMWARE
From: Bryan O'Donoghue
Date: Mon Apr 20 2026 - 21:23:41 EST
On 20/04/2026 20:57, Christopher Obbard wrote:
Hi Bryan,
The background for this was to ensure the firmware is available in a
system image
or copied into the initrd if the driver is built-in. This is done in a
CI environment without
access to the hardware.
Debian's initramfs-tools looks at MODULE_FIRWMARE and copies those
files into the
initrd if the driver is built-in. For now, a workaround for me could
be to just manually copy
the firmware into the initrd and drop this patch.
I didn't get to the bottom of modifying the firmware loading code to
make the driver
defer probe to when the rootfs was ready and instead just threw the
firmware into
the initrd, but that's another story.
On Mon, 20 Apr 2026 at 11:20, Bryan O'Donoghue <bod@xxxxxxxxxx> wrote:
On 19/04/2026 23:39, Christopher Obbard wrote:
The driver loads firmware blobs at runtime via request_firmware()
but does not currently advertise the possible filenames. Add
MODULE_FIRMWARE() entries for all known firmware variants so they are
visible via modinfo and can be picked up by user space tooling.
What about the board dtsi files ?
I really am not keen on adding all of the firmware from the board dts files as
MODULE_FIRMWARE entries into the driver, it then becomes two lists to
maintain. What do you think?
BUT talking of two lists to maintain, I am essentially duplicating fwname in
MODULE_FIRMWARE, so perhaps my argument is moot.
For my use-case, it may make sense to "teach" the initrd generator to look at
the firmware-name entries from the dts files I am building for. But that is also
not ideal.
Cheers!
Chris
I think its reasonable to keep a list of firmware that is supplied in linux-firmware in the MODULE_FIRMWARE() list.
AFAIK paths such as "qcom/sdm845/SHIFT/axolotl/venus.mbn"; are not in linux-firmware so .. we shoudln't expect tooling to populate them into initrd.
Reviewed-by: Bryan O'Donoghue <bod@xxxxxxxxxx>
---
bod