Re: [PATCH v2 2/2] arm64: dts: qcom: Add support for Xiaomi 17 Ultra phones

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] arm64: dts: qcom: nezha: swapped unit addresses in pdp_mem reserved-memory
- [Medium] arm64: dts: qcom: nezha: inconsistent vendor casing in firmware-name paths
--

commit 78a525e62bca89477d8de3ba74ccb271e603f04a
Author: Igor Belwon <igor.belwon@mentallysanemainliners.org>

arm64: dts: qcom: Add support for Xiaomi 17 Ultra phones

This patch adds initial Device Tree support for the Xiaomi 17 Ultra
(nezha) China and EEA variants based on the Qualcomm Kaanapali SoC.

> diff --git a/arch/arm64/boot/dts/qcom/kaanapali-xiaomi-nezha-common.dtsi b/arch/arm64/boot/dts/qcom/kaanapali-xiaomi-nezha-common.dtsi
> new file mode 100644
> index 0000000000000..f4125d32dc05f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/kaanapali-xiaomi-nezha-common.dtsi
> @@ -0,0 +1,883 @@

[ ... ]

> +	reserved-memory {
> +		/*
> +		 * If we do not have this exact region with this exact name
> +		 * present, the bootloader disables the display panel and
> +		 * for some reason it cannot be re-enabled.
> +		 */
> +		splashmem: splash_region {
> +			reg = <0x0 0xfc800000 0x0 0x2b00000>;
> +			no-map;
> +		};
> +
> +		/delete-node/ pdp@81200000;
> +		pdp_mem: pdp@81300000 {
> +			reg = <0x0 0x81200000 0x0 0x200000>;
> +			no-map;
> +		};

[Severity: Medium]
Are the unit addresses in /delete-node/ pdp@81200000 and pdp@81300000
swapped here?

In arch/arm64/boot/dts/qcom/kaanapali.dtsi, pdp_mem is defined at
0x81300000:

	pdp_mem: pdp@81300000 {
		reg = <0x0 0x81300000 0x0 0x100000>;
		no-map;
	};

Because pdp@81200000 does not exist in kaanapali.dtsi, deleting
pdp@81200000 is a no-op, and pdp_mem: pdp@81300000 ends up with a unit
address that does not match its reg base of 0x81200000, triggering DTC
unit_address_vs_reg warnings when building the DTBs. Should this delete
pdp@81300000 and define pdp_mem: pdp@81200000 instead?

[ ... ]

> +&gpu {
> +	status = "okay";
> +};
> +
> +&gpu_zap_shader {
> +	firmware-name = "qcom/kaanapali/xiaomi/nezha/gen80200_zap.mbn";
> +};

[ ... ]

> +&remoteproc_adsp {
> +	firmware-name = "qcom/kaanapali/Xiaomi/nezha/adsp.mbn",
> +			"qcom/kaanapali/Xiaomi/nezha/adsp_dtb.mbn";
> +
> +	status = "okay";
> +};
> +
> +&remoteproc_cdsp {
> +	firmware-name = "qcom/kaanapali/Xiaomi/nezha/cdsp.mbn",
> +			"qcom/kaanapali/Xiaomi/nezha/cdsp_dtb.mbn";
> +
> +	status = "okay";
> +};
> +
> +&remoteproc_soccp {
> +	firmware-name = "qcom/kaanapali/Xiaomi/nezha/soccp.mbn",
> +			"qcom/kaanapali/Xiaomi/nezha/soccp_dtb.mbn";
> +};

[Severity: Medium]
Will firmware loading fail on case-sensitive filesystems due to the
inconsistent casing of the vendor directory between gpu_zap_shader
("qcom/kaanapali/xiaomi/nezha/...") and the remoteproc nodes
remoteproc_adsp, remoteproc_cdsp, and remoteproc_soccp
("qcom/kaanapali/Xiaomi/nezha/...")?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261017-nezha-v2-0-44c95e1a9d6a@mentallysanemainliners.org?part=2