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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] SCMI providers `scmi3` and `scmi11` are left disabled by default, causing indefinite probe deferral for their consumers.
- [High] SCMI nodes scmi57 through scmi63 use GIC_ESPI 32-38 with conflicting trigger types, overlapping the statically assigned apps_smmu_0 interrupts.
--

--- Patch [2]: [PATCH v5 2/7] arm64: dts: qcom: Add device tree for Nord GearVM variant ---
commit 4395a14fff5eeaf5f222d6a5a7f0fa310adfb7bf
Author: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>

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

This patch adds a device tree include for the Nord GearVM variant. It covers
SCMI shared memory regions, GENI SE QUP blocks (I2C/SPI/UART), and the UFS
host controller which use SCMI for power and performance domains.

> 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..8f29b5f24ef8c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/nord-gearvm.dtsi
> @@ -0,0 +1,2847 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include "nord.dtsi"
> +
> +&firmware {

[ ... ]

> +	scmi57: scmi-57 {
> +		compatible = "qcom,scmi-smc";
> +		arm,smc-id = <0xc6008012>;
> +		shmem = <&shmem57>;
> +		interrupts = <GIC_ESPI 32 IRQ_TYPE_EDGE_RISING>;

[Severity: High]
Does this interrupt mapping conflict with the SMMU context bank interrupts?

scmi57 through scmi63 claim GIC_ESPI 32 through 38 with IRQ_TYPE_EDGE_RISING,
but these physical lines perfectly overlap with apps_smmu_0, which statically
claims them as IRQ_TYPE_LEVEL_HIGH from the base nord.dtsi without being
overridden.

The kernel's IRQ subsystem will likely reject mapping the same physical
interrupt with conflicting trigger types, leading to a probe failure for either
the SMMU or the SCMI channels.

> +		interrupt-names = "a2p";

[ ... ]

> +&i2c0 {
> +	compatible = "qcom,sa8797p-geni-i2c",
> +		     "qcom,sa8255p-geni-i2c";
> +	power-domains = <&scmi11_pd 0>,
> +			<&scmi11_dvfs 0>;

[Severity: High]
Since this consumer strictly relies on scmi11_pd, will it face indefinite probe
deferral because the scmi-11 provider is left disabled by default in this
variant DT?

The same issue appears to apply to ufs_mem_hc, which relies on scmi3_pd
but has its provider disabled as well.

> +	power-domain-names = "power",
> +			     "perf";
> +};

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