Re: [PATCH v4 4/4] arm64: dts: qcom: Add device tree for SA8797P Ride board

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Unnecessary enabling of the `scmi15` node without any consumers in the device tree.
--

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

arm64: dts: qcom: Add device tree for SA8797P Ride board

This commit adds the initial device tree for the Qualcomm SA8797P Ride
reference board. It configures primary and secondary serial ports, enables
UFS storage support, and defines various thermal zones sourced from SCMI.

> diff --git a/arch/arm64/boot/dts/qcom/sa8797p-ride.dts b/arch/arm64/boot/dts/qcom/sa8797p-ride.dts
> new file mode 100644
> index 0000000000000..d1c28698a9709
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sa8797p-ride.dts

[ ... ]

> +&scmi11 {
> +	status = "okay";
> +};
> +
> +&scmi15 {
> +	status = "okay";
> +};

[Severity: Medium]
Is it necessary to enable the scmi15 node here?

Looking at the device tree, there don't appear to be any consumers for scmi15
such as scmi15_pd or scmi15_dvfs.

Enabling this channel could result in spurious SCMI probes during boot. This
can execute unnecessary SMC calls and potentially cause boot delays, SCMI
timeouts, or firmware errors if the channel is not provisioned for this
virtual machine.

Could this be a mix-up with uart15? I noticed uart15 is enabled in this patch,
but it typically draws its power domains and performance scaling from scmi11
rather than scmi15.

[ ... ]

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