linux-kernel - Re: [PATCH 2/2] media: iris: Enable Gen2 HFI on SC7280

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2uih6xdzarkwnvhlhv5kznmdwo4jorqvsrb7xxrxgr6vprx3ey@4kx45k5i3c4y>
Date: Mon, 9 Feb 2026 14:35:55 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Dikshita Agarwal <dikshita.agarwal@....qualcomm.com>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        Vikash Garodia <vikash.garodia@....qualcomm.com>,
        Abhinav Kumar <abhinav.kumar@...ux.dev>,
        Bryan O'Donoghue <bod@...nel.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] media: iris: Enable Gen2 HFI on SC7280

On Mon, Feb 09, 2026 at 05:04:48PM +0530, Dikshita Agarwal wrote:
> 
> 
> On 2/9/2026 3:32 PM, Konrad Dybcio wrote:
> > On 2/9/26 10:45 AM, Dikshita Agarwal wrote:
> >> SC7280 supports both Gen1 and Gen2 HFI firmware. The driver continues to
> >> use Gen1 by default, but boards that intend to use Gen2 firmware can
> >> opt‑in by specifying a Gen2 image through the Device Tree
> >> 'firmware-name' property.
> >>
> >> Based on this property and the availability of the referenced
> >> firmware binary, the driver selects the appropriate HFI generation and
> >> updates its platform data accordingly. Boards that do not
> >> specify a Gen2 firmware, or where the firmware is not present,
> >> automatically fall back to Gen1.
> >>
> >> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@....qualcomm.com>
> >> ---
> > 
> > [...]
> > 
> >> +int iris_update_platform_data(struct iris_core *core)
> >> +{
> >> +	const char *fwname = NULL;
> >> +	const struct firmware *fw;
> >> +	int ret;
> >> +
> >> +	if (of_device_is_compatible(core->dev->of_node, "qcom,sc7280-venus")) {
> >> +		ret = of_property_read_string_index(core->dev->of_node, "firmware-name", 0,
> >> +					    &fwname);
> >> +		if (ret)
> >> +			return 0;
> >> +
> >> +		if (strstr(fwname, "gen2")) {
> >> +			ret = request_firmware(&fw, fwname, core->dev);
> >> +			if (ret) {
> >> +				dev_err(core->dev, "Specified firmware is not present\n");
> >> +				return ret;
> > 
> > This is fragile - if someone names names their gen1 firmware something like
> > "myproduct_gen2_vidfw.mbn", it's going to match..
> > 
> > Could we instead do something like the explicit format checks in
> > venus/hfi_msgs.c : sys_get_prop_image_version(), based on the **contents**
> > of the binary?
> > 
> 
> I agree that checking for "gen2" as a substring in the firmware name is not
> reliable. Unfortunately, we cannot
> usevenus/hfi_msgs.c:sys_get_prop_image_version() (or any Gen1 HFI query) to
> probe the contents of the binary here, because Gen1 vs Gen2 have
> incompatible HFI protocols—probing a Gen2 image with Gen1 HFI (or
> vice‑versa) isn’t viable in this path.

Can't we perform Gen2 query on Gen1 firmware, get the error and act
accordingly? Or, better, perform Gen1 query on Gen2 firmware, receive
the error from the firmware and act? In the end, your team is handling
the firmware. If you want to support both interfaces, it should be a
runtime check rather than filename matching.

> 
> To avoid accidental matches, I can switch to an exact filename match
> instead. That way, only the specific Gen2 image (for example
> "qcom/vpu/vpu20_p1_gen2.mbn") will trigger the Gen2 path, and boards that

How do you detect that for the OEM-signed firmware, which can have
random name?

> want to use Gen2 can opt in by naming the firmware accordingly.
> 
> Thanks,
> Dikshita
> 
> > Konrad

-- 
With best wishes
Dmitry