Re: [PATCH v13 2/6] arm64: dts: qcom: Add device tree for Nord GearVM variant

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] GENI QUP Serial Engine power domains are incorrectly mapped to SCMI channels based on their serial protocol rather than their physical QUPv3 macro instance.
--

commit 41071503143d39ef303989d323bfed347d9037f8
Author: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>

arm64: dts: qcom: Add device tree for Nord GearVM variant

Add SoC-level device tree include for Nord GearVM variant, where a VM controls
platform resources (clocks, regulators, powerdomains, etc.) as an SCMI server.

> diff --git a/arch/arm64/boot/dts/qcom/nord-gearvm.dtsi b/arch/arm64/boot/dts/qcom/nord-gearvm.dtsi
> new file mode 100644
> index 0000000000000..5514f9a6f49f5
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/nord-gearvm.dtsi

[ ... ]

> +&i2c15 {
> +	compatible = "qcom,sa8797p-geni-i2c",
> +		     "qcom,sa8255p-geni-i2c";
> +	power-domains = <&scmi9_pd 15>,
> +			<&scmi9_dvfs 15>;
> +	power-domain-names = "power",
> +			     "perf";
> +};

[Severity: High]
Are the power domains mapped incorrectly here? SE15 is assigned to the
scmi9 domain when configured as I2C.

[ ... ]

> +&spi15 {
> +	compatible = "qcom,sa8797p-geni-spi",
> +		     "qcom,sa8255p-geni-spi";
> +	power-domains = <&scmi10_pd 15>,
> +			<&scmi10_dvfs 15>;
> +	power-domain-names = "power",
> +			     "perf";
> +};

[Severity: High]
However, the exact same physical SE15 hardware block is assigned to a
completely different domain (scmi10) when configured as SPI.

[ ... ]

> +&uart15 {
> +	compatible = "qcom,sa8797p-geni-debug-uart",
> +		     "qcom,sa8255p-geni-debug-uart";
> +	power-domains = <&scmi11_pd 15>,
> +			<&scmi11_dvfs 15>;
> +	power-domain-names = "power",
> +			     "perf";
> +};

[Severity: High]
And here, the same SE15 block is assigned to yet another domain (scmi11)
when configured as UART.

Does this incorrectly assign the power domains based on the serial protocol
rather than mapping per physical QUPv3 hardware macro instance? 

If hardware peripherals request the wrong power and performance domains from
the firmware, could the SCMI server reject the requests or manipulate the
wrong physical domains, resulting in the peripherals failing to probe?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828034958.3165-1-shengchao.guo@oss.qualcomm.com?part=2