Re: [PATCH v3 2/5] arm64: dts: qcom: Add device tree for Nord SoC series

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] SCMI shared memory phandles are incorrectly ordered, breaking TX/RX communication.
- [High] The `ufs_mem_hc` node is missing the mandatory `reg` property.
--

commit cfa0d5607f866c28a7b366f81351c85f19172eee
Author: Shawn Guo <shengchao.guo@oss.qualcomm.com>

arm64: dts: qcom: Add device tree for Nord SoC series

This commit adds the base device tree include (nord.dtsi) for the Nord SoC
series, describing the core hardware components such as CPUs, SCMI interfaces,
thermal sensors, and memory regions.

> diff --git a/arch/arm64/boot/dts/qcom/nord.dtsi b/arch/arm64/boot/dts/qcom/nord.dtsi
> new file mode 100644
> index 0000000000000..954a2b23a4fa3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/nord.dtsi
> @@ -0,0 +1,4513 @@

[ ... ]

> +	firmware: firmware {
> +		scm {
> +			compatible = "qcom,scm-nord",
> +				     "qcom,scm";
> +			qcom,dload-mode = <&tcsr 0x79000>;
> +		};
> +
> +		pdp_scmi: scmi {
> +			compatible = "arm,scmi";
> +			mboxes = <&pdp0_mbox 0>,
> +				 <&pdp0_mbox 11>,
> +				 <&pdp0_mbox 1>;
> +			mbox-names = "tx",
> +				     "tx_reply",
> +				     "rx";
> +			shmem = <&pdp0_a2p>,
> +				<&pdp0_p2a>;

[Severity: High]
Is this shared memory order correct for the SCMI driver?

The Linux SCMI driver typically expects index 0 for the TX channel and index 1
for the RX channel. Since <&pdp0_a2p> is Agent-to-Processor (RX) and
<&pdp0_p2a> is Processor-to-Agent (TX), does placing a2p at index 0 cause
the SCMI driver to transmit on the RX region and receive on the TX region?

> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			cpu_perf: protocol@13 {
> +				reg = <0x13>;
> +				#clock-cells = <1>;
> +			};
> +		};

[ ... ]

> +		rng: rng@10c3000 {
> +			compatible = "qcom,nord-trng",
> +				     "qcom,trng";
> +			reg = <0x0 0x010c3000 0x0 0x1000>;
> +		};
> +
> +		ufs_mem_hc: ufshc@1d44000 {
> +			compatible = "qcom,nord-ufshc",
> +				     "qcom,ufshc",
> +				     "jedec,ufs-2.0";
> +			interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>;
> +			lanes-per-direction = <2>;
> +			iommus = <&apps_smmu_0 0x14c0 0x0>;
> +			dma-coherent;
> +			msi-parent = <&gic_its 0x14c0>;
> +		};

[Severity: High]
Is the reg property missing from this node?

The UFS host controller node is declared with a unit address (@1d44000), but
without a corresponding reg property, won't the UFS driver fail to map its
registers during probe?

This might also trigger a dtc unit_address_vs_reg compilation warning.

> +
> +		tcsr_mutex: hwlock@1f40000 {
> +			compatible = "qcom,tcsr-mutex";
> +			reg = <0x0 0x01f40000 0x0 0x20000>;
> +			#hwlock-cells = <1>;
> +		};

[ ... ]

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