Re: [PATCH 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 3 potential issue(s) to consider:
- [Medium] arm64: dts: qcom: inconsistent xiaomi vendor casing in nezha firmware-name
- [Low] arm64: dts: qcom: mismatched unit-address on pdp@81300000 reserved-memory node
- [Low] arm64: dts: qcom: unused ts_vdd_regulator and empty spi19 node enabled
--

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

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

This commit adds device tree files for the Xiaomi 17 Ultra phones (China and
EEA variants), which are 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..fce2d9e0f8b2f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/kaanapali-xiaomi-nezha-common.dtsi
> @@ -0,0 +1,899 @@

[ ... ]

> +	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@81300000;
> +		pdp_mem: pdp@81300000 {
> +			reg = <0x0 0x81200000 0x0 0x200000>;
> +			no-map;
> +		};

[Severity: Low]
Since pdp_mem moves the base address in reg to 0x81200000 after deleting
pdp@81300000, should the node name be updated to pdp@81200000 so the unit
address matches reg and avoids a dtc warning?

> +
> +		/delete-node/ adspslpi@a1400000;
> +		adspslpi_mem: adspslpi@a1400000 {
> +			reg = <0x0 0xa1400000 0x0 0x5580000>;
> +			no-map;
> +		};
> +	};
> +
> +	ts_vdd_regulator: regulator-tsvdd {
> +		compatible = "regulator-fixed";
> +		regulator-name = "ts_vdd";
> +		regulator-min-microvolt = <3000000>;
> +		regulator-max-microvolt = <3000000>;
> +
> +		gpio = <&tlmm 215 GPIO_ACTIVE_HIGH>;
> +		enable-active-high;
> +	};
> +};

[ ... ]

> +&gpu {
> +	status = "okay";
> +};
> +
> +&gpu_zap_shader {
> +	firmware-name = "qcom/kaanapali/xiaomi/nezha/gen80200_zap.mbn";
> +};
> +
> +&i2c5 {
> +	status = "okay";
> +
> +	bq27z561: fuel-gauge@55 {
> +		compatible = "ti,bq27z561";
> +		reg = <0x55>;
> +		monitored-battery = <&battery>;
> +	};
> +};
> +
> +&spi19 {
> +	status = "okay";
> +
> +	/* Synaptics TCM touch screen */
> +};

[Severity: Low]
With the Synaptics TCM touch screen child node not yet populated in spi19,
should spi19 and ts_vdd_regulator be dropped or left disabled until the touch
screen node is added?

Currently spi19 probes an empty controller and ts_vdd_regulator registers an
unreferenced GPIO regulator on tlmm 215 that regulator_late_cleanup()
Subsequently disables.

[ ... ]

> +&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 with -ENOENT on case-sensitive filesystems for
either the GPU or the remote processors?

Above, gpu_zap_shader uses lowercase "xiaomi" in its path:

	firmware-name = "qcom/kaanapali/xiaomi/nezha/gen80200_zap.mbn";

whereas remoteproc_adsp, remoteproc_cdsp, and remoteproc_soccp use capitalized
"Xiaomi":

	firmware-name = "qcom/kaanapali/Xiaomi/nezha/adsp.mbn",
			"qcom/kaanapali/Xiaomi/nezha/adsp_dtb.mbn";

Should these all use the same vendor directory casing?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261016-nezha-v1-0-a39900dfaadd@mentallysanemainliners.org?part=2