[PATCH] media: venus: declare firmware files via MODULE_FIRMWARE

[PATCH] media: venus: declare firmware files via MODULE_FIRMWARE

[Christopher Obbard]

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.

Signed-off-by: Christopher Obbard <christopher.obbard@linaro.org>
---
 drivers/media/platform/qcom/venus/core.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c
index 7e639760c41d..7ed7cffb333b 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -1119,6 +1119,16 @@ static const struct venus_resources qcm2290_res = {
 	.min_fw = &min_fw,
 };
 
+MODULE_FIRMWARE("qcom/venus-1.8/venus.mbn");
+MODULE_FIRMWARE("qcom/venus-4.2/venus.mbn");
+MODULE_FIRMWARE("qcom/venus-4.4/venus.mbn");
+MODULE_FIRMWARE("qcom/venus-4.4/venus.mdt");
+MODULE_FIRMWARE("qcom/venus-5.2/venus.mbn");
+MODULE_FIRMWARE("qcom/venus-5.4/venus.mbn");
+MODULE_FIRMWARE("qcom/vpu-1.0/venus.mbn");
+MODULE_FIRMWARE("qcom/vpu-2.0/venus.mbn");
+MODULE_FIRMWARE("qcom/venus-6.0/venus.mbn");
+
 static const struct of_device_id venus_dt_match[] = {
 	{ .compatible = "qcom,msm8916-venus", .data = &msm8916_res, },
 	{ .compatible = "qcom,msm8996-venus", .data = &msm8996_res, },

---
base-commit: 4f5b4b748ac75683d61c304ee3ee0db235e8f312
change-id: 20260419-wip-obbardc-qcom-venus-firmware-abdd35b05a22

Best regards,
-- 
Christopher Obbard <christopher.obbard@linaro.org>

Re: [PATCH] media: venus: declare firmware files via MODULE_FIRMWARE

[Bryan O'Donoghue]

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.
> 
> Signed-off-by: Christopher Obbard <christopher.obbard@linaro.org>
> ---
>   drivers/media/platform/qcom/venus/core.c | 10 ++++++++++
>   1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c
> index 7e639760c41d..7ed7cffb333b 100644
> --- a/drivers/media/platform/qcom/venus/core.c
> +++ b/drivers/media/platform/qcom/venus/core.c
> @@ -1119,6 +1119,16 @@ static const struct venus_resources qcm2290_res = {
>   	.min_fw = &min_fw,
>   };
> 
> +MODULE_FIRMWARE("qcom/venus-1.8/venus.mbn");
> +MODULE_FIRMWARE("qcom/venus-4.2/venus.mbn");
> +MODULE_FIRMWARE("qcom/venus-4.4/venus.mbn");
> +MODULE_FIRMWARE("qcom/venus-4.4/venus.mdt");
> +MODULE_FIRMWARE("qcom/venus-5.2/venus.mbn");
> +MODULE_FIRMWARE("qcom/venus-5.4/venus.mbn");
> +MODULE_FIRMWARE("qcom/vpu-1.0/venus.mbn");
> +MODULE_FIRMWARE("qcom/vpu-2.0/venus.mbn");
> +MODULE_FIRMWARE("qcom/venus-6.0/venus.mbn");
> +
>   static const struct of_device_id venus_dt_match[] = {
>   	{ .compatible = "qcom,msm8916-venus", .data = &msm8916_res, },
>   	{ .compatible = "qcom,msm8996-venus", .data = &msm8996_res, },
> 
> ---
> base-commit: 4f5b4b748ac75683d61c304ee3ee0db235e8f312
> change-id: 20260419-wip-obbardc-qcom-venus-firmware-abdd35b05a22
> 
> Best regards,
> --
> Christopher Obbard <christopher.obbard@linaro.org>
> 
> 

What about the board dtsi files ?

#( 04/20/26@10:29 )( deckard@inspiron14p-linux 
):~/Development/linux@arm64-laptops-v7.1-rc6-camss✗✗✗
    grep -r "venus.mbn" *
arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi:	firmware-name 
= "qcom/sm8250/xiaomi/elish/venus.mbn";
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts:	firmware-name = 
"qcom/qcm6490/fairphone5/venus.mbn";
arch/arm64/boot/dts/qcom/msm8996-xiaomi-gemini.dts:	firmware-name = 
"qcom/msm8996/gemini/venus.mbn";
arch/arm64/boot/dts/qcom/msm8996-oneplus3.dts:	firmware-name = 
"qcom/msm8996/oneplus3/venus.mbn";
arch/arm64/boot/dts/qcom/sdm845-sony-xperia-tama.dtsi:	firmware-name = 
"qcom/sdm845/Sony/tama/venus.mbn";
arch/arm64/boot/dts/qcom/sdm845-xiaomi-polaris.dts:	firmware-name = 
"qcom/sdm845/Xiaomi/polaris/venus.mbn";
arch/arm64/boot/dts/qcom/sm8250-sony-xperia-edo.dtsi:	firmware-name = 
"qcom/sm8250/Sony/edo/venus.mbn";
arch/arm64/boot/dts/qcom/sm8250-xiaomi-pipa.dts:	firmware-name = 
"qcom/sm8250/xiaomi/pipa/venus.mbn";
arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi:	firmware-name = 
"qcom/sdm845/OnePlus/enchilada/venus.mbn";
arch/arm64/boot/dts/qcom/msm8996pro-xiaomi-scorpio.dts:	firmware-name = 
"qcom/msm8996/scorpio/venus.mbn";
arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi:	firmware-name = 
"qcom/sdm845/Google/blueline/venus.mbn";
arch/arm64/boot/dts/qcom/qcm6490-shift-otter.dts:	firmware-name = 
"qcom/qcm6490/SHIFT/otter/venus.mbn";
arch/arm64/boot/dts/qcom/sdm845-shift-axolotl.dts:	firmware-name = 
"qcom/sdm845/SHIFT/axolotl/venus.mbn";
arch/arm64/boot/dts/qcom/msm8996-oneplus3t.dts:	firmware-name = 
"qcom/msm8996/oneplus3t/venus.mbn";
arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-common.dtsi: 
firmware-name = "qcom/sdm845/Xiaomi/beryllium/venus.mbn";
arch/arm64/boot/dts/qcom/msm8996pro-xiaomi-natrium.dts:	firmware-name = 
"qcom/msm8996/natrium/venus.mbn";
drivers/media/platform/qcom/venus/core.c:	.fwname = 
"qcom/venus-1.8/venus.mbn",
drivers/media/platform/qcom/venus/core.c:	.fwname = 
"qcom/venus-4.2/venus.mbn",
drivers/media/platform/qcom/venus/core.c:	.fwname = 
"qcom/venus-4.4/venus.mbn",
drivers/media/platform/qcom/venus/core.c:	.fwname = 
"qcom/venus-5.2/venus.mbn",
drivers/media/platform/qcom/venus/core.c:	.fwname = 
"qcom/venus-5.2/venus.mbn",
drivers/media/platform/qcom/venus/core.c:	.fwname = 
"qcom/venus-5.4/venus.mbn",
drivers/media/platform/qcom/venus/core.c:	.fwname = 
"qcom/vpu-1.0/venus.mbn",
drivers/media/platform/qcom/venus/core.c:	.fwname = 
"qcom/vpu-2.0/venus.mbn",
drivers/media/platform/qcom/venus/core.c:	.fwname = 
"qcom/vpu-2.0/venus.mbn",
drivers/media/platform/qcom/venus/core.c:	.fwname = 
"qcom/venus-6.0/venus.mbn",
drivers/media/platform/qcom/venus/core.c:	.fwname = 
"qcom/vpu-2.0/venus.mbn",
drivers/media/platform/qcom/iris/iris_platform_gen1.c:	.fwname = 
"qcom/vpu-1.0/venus.mbn",

---
bod

Re: [PATCH] media: venus: declare firmware files via MODULE_FIRMWARE

[Christopher Obbard]

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@kernel.org> 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

Re: [PATCH] media: venus: declare firmware files via MODULE_FIRMWARE

[Bryan O'Donoghue]

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@kernel.org> 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@kernel.org>

---
bod

Re: [PATCH] media: venus: declare firmware files via MODULE_FIRMWARE

[Christopher Obbard]

Hi Bryan,

On Tue, 2026-04-21 at 02:23 +0100, Bryan O'Donoghue wrote:
> 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@kernel.org> 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.

In latest linux-firmware we have:

$ find -type f | grep -i venus
./qcom/venus-6.0/venus.mbn
./qcom/venus-5.2/venus.mbn
./qcom/venus-1.8/venus.mbn
./qcom/venus-4.2/venus.mbn
./qcom/venus-5.4/venus.mbn

So I wonder if I should send v2 adding MODULE_FIRMWARE entries for just those files in linux-firmware?


Cheers!

Chris

Re: [PATCH] media: venus: declare firmware files via MODULE_FIRMWARE

[Dmitry Baryshkov]

On Tue, Apr 21, 2026 at 10:10:14PM +0100, Christopher Obbard wrote:
> Hi Bryan,
> 
> On Tue, 2026-04-21 at 02:23 +0100, Bryan O'Donoghue wrote:
> > 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@kernel.org> 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.
> 
> In latest linux-firmware we have:
> 
> $ find -type f | grep -i venus
> ./qcom/venus-6.0/venus.mbn
> ./qcom/venus-5.2/venus.mbn
> ./qcom/venus-1.8/venus.mbn
> ./qcom/venus-4.2/venus.mbn
> ./qcom/venus-5.4/venus.mbn
> 
> So I wonder if I should send v2 adding MODULE_FIRMWARE entries for just those files in linux-firmware?

I'd suggest doing a simpler thing. Add firmware-name strings to
corresponding DT files (updating those when necessary) and add a warning
to iris / venus drivers when there is no firmware in the DT.

Then we won't need to add MODULE_FIRMWARE to the module. Instead you'd
have the standard code which fetches firmware files from the DT.

> 
> 
> Cheers!
> 
> Chris

-- 
With best wishes
Dmitry