Re: [PATCH] arm64: dts: qcom: talos-evk-som: Add firmware-name to QUPv3 nodes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Removing the TrustZone dependency for QUP firmware breaks earlycon and standard serial console initialization.
- [High] The commit claims to handle access control permissions within Linux, but no such logic exists.
--

--- Patch [1]: [PATCH] arm64: dts: qcom: talos-evk-som: Add firmware-name to QUPv3 nodes ---
commit 2c22f3348260193e8037f117d786bf9e0ca0dd64
Author: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>

arm64: dts: qcom: talos-evk-som: Add firmware-name to QUPv3 nodes

This commit adds the firmware-name property to QUPv3 nodes for the
talos-evk-som board. It shifts the responsibility of loading Serial Engine
(SE) firmware from TrustZone to Linux.

> Handle SE assignments and access control permissions directly within Linux,
> removing the dependency on TrustZone.

[Severity: High]
The commit message states that access control permissions are handled
directly within Linux. Is this access control logic actually implemented?

Looking at the qcom-geni-se driver, there does not appear to be code that
configures hardware access control (such as QUP wrapper ACL registers, XPUs,
or SMMU protections) that TrustZone would normally enforce.

Does this change bypass a security boundary without providing the stated
replacement in Linux?

> diff --git a/arch/arm64/boot/dts/qcom/talos-evk-som.dtsi b/arch/arm64/boot/dts/qcom/talos-evk-som.dtsi
> --- a/arch/arm64/boot/dts/qcom/talos-evk-som.dtsi
> +++ b/arch/arm64/boot/dts/qcom/talos-evk-som.dtsi
[ ... ]
> @@ -411,10 +411,14 @@ usb2_en: usb2-en-state {
>  };
>  
>  &qupv3_id_0 {
> +	firmware-name = "qcom/qcs615/qupv3fw.elf";
> +
>  	status = "okay";
>  };

[Severity: High]
Will relying on Linux to load the QUP firmware break earlycon and standard
serial console initialization?

If the hardware remains uninitialized during early boot,
qcom_geni_serial_earlycon_setup() will fail when geni_se_read_proto() cannot
detect the UART protocol and abort the earlycon setup.

Furthermore, standard console registration invokes request_firmware() via
geni_load_se_firmware(). Since this occurs before the root filesystem is
mounted, will this fail with -ENOENT and drop the console registration?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260805-talos-evk-qupv3-firmware-name-v1-1-3ebd5e5578bd@oss.qualcomm.com?part=1