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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] All thermal zones incorrectly configure their highest trip point as 'passive' instead of 'critical'.
- [High] The QUPv3 wrapper nodes (`qupv3_0`, `qupv3_1`, `qupv3_2`) and their child serial engines are missing the mandatory `clocks` and `clock-names` properties.
- [Medium] The QUPv3 wrapper nodes lack the `dma-coherent;` property despite operating behind DMA-coherent SMMUs.
--

--- Patch [1]: [PATCH v4 1/4] arm64: dts: qcom: Add device tree for Nord SoC series ---
commit 5f24b1554bc5bc9f0d13a6a874f148ee166082f5
Author: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Subject: arm64: dts: qcom: Add device tree for Nord SoC series

This commit adds the base device tree include for the Qualcomm Nord SoC
series. It describes core hardware components like CPUs, interrupt
controllers, GPIO, thermal sensors, memory mappings, and QUP blocks.

> diff --git a/arch/arm64/boot/dts/qcom/nord.dtsi b/arch/arm64/boot/dts/qcom/nord.dtsi
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/nord.dtsi
[ ... ]
> +	soc: soc@0 {
> +		compatible = "simple-bus";
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		dma-ranges = <0 0 0 0 0x10 0>;
> +		ranges = <0 0 0 0 0x10 0>;
> +
> +		qupv3_2: geniqup@8c0000 {
> +			compatible = "qcom,geni-se-qup";
> +			reg = <0x0 0x008c0000 0x0 0x2000>;
> +			#address-cells = <2>;
> +			#size-cells = <2>;
> +			iommus = <&apps_smmu_0 0x15a3 0x0>;
> +			ranges;

[Severity: High]
Are these QUPv3 wrapper nodes (and their child serial engines) missing
the mandatory clocks and clock-names properties?

The qcom,geni-se-qup compatible string instructs the driver to request
two clocks (m-ahb and s-ahb). Because these properties are omitted, the
probe function will fail immediately with -ENOENT when validating the
clock count, leaving the QUP wrappers and all their child serial engines
unusable.

[Severity: Medium]
Should this node also include the dma-coherent property?

The apps_smmu_0, apps_smmu_1, and apps_smmu_2 IOMMUs are explicitly
marked as dma-coherent. However, because the parent soc node does not
declare dma-coherent, the QUP wrappers must explicitly define it so that
child serial engines inherit the coherency property.

Omitting it causes the DMA API to fall back to non-coherent mappings,
leading to unnecessary CPU cache maintenance operations on every DMA
transfer.

> +
> +			i2c14: i2c@880000 {
[ ... ]
> +	thermal_zones: thermal-zones {
> +		ddr-0-0-thermal {
> +			polling-delay-passive = <0>;
> +			polling-delay = <0>;
> +			thermal-sensors = <&tsens0 0>;
> +
> +			trips {
> +				trip-point0 {
> +					temperature = <105000>;
> +					hysteresis = <10000>;
> +					type = "passive";
> +				};
> +
> +				trip-point1 {
> +					temperature = <115000>;
> +					hysteresis = <10000>;
> +					type = "passive";
> +				};

[Severity: High]
Is the highest trip point intentionally configured as passive instead
of critical here and across the other thermal zones?

When the hardware reaches high temperature thresholds like 115C or 125C,
having the type set to passive means the Linux thermal core will only
attempt passive cooling (throttling) and will not initiate an emergency
shutdown.

Without a critical trip point, temperatures could continue to rise until
the hardware's protection circuit forcibly cuts power, which can lead to
data corruption or permanent hardware damage.

> +			};

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