Re: [PATCH v4 2/4] arm64: dts: qcom: Add device tree for Nord SA8797P SoC

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Required SCMI providers (scmi11 and scmi3) are left disabled in the SoC DTSI, causing peripheral probe failures.
--

--- Patch [2]: [PATCH v4 2/4] arm64: dts: qcom: Add device tree for Nord SA8797P SoC ---
commit 59c8d1264399eb0988cc4614fe131ec99cdf308f
Author: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>

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

Add SoC-level device tree include for SA8797P, an automotive variant
of the Nord SoC family. The device tree introduces multiple peripherals
and SCMI-based firmware communication channels for power and performance
domain management.

> diff --git a/arch/arm64/boot/dts/qcom/nord-sa8797p.dtsi b/arch/arm64/boot/dts/qcom/nord-sa8797p.dtsi
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/nord-sa8797p.dtsi
[ ... ]
> +&ufs_mem_hc {
> +	compatible = "qcom,sa8797p-ufshc",
> +		     "qcom,sa8255p-ufshc";
> +	reg = <0x0 0x01d44000 0x0 0x3000>;
> +	power-domains = <&scmi3_pd 0>;
> +};

[Severity: Medium]
Will this peripheral and others (like UART, SPI, and I2C) fail to probe
because their underlying SCMI providers remain disabled?

The scmi-common.dtsi file defines the SCMI instances with
status = "disabled";. While nord-sa8797p.dtsi adds references to scmi11_pd,
scmi11_dvfs, and scmi3_pd for these devices, it does not provide an
overriding status = "okay"; for &scmi11 and &scmi3.

Could this cause the device driver core to permanently defer probing for
these consumers due to the disabled power domain providers?

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