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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Missing `critical` thermal trip points in all SoC thermal zones.
- [High] Sub-page `no-map` reserved memory regions for SCMI shared memory leave parts of the physical 4KB page unreserved, leading to cache attribute aliasing.
- [Medium] All QUPv3 wrapper nodes and their child serial engines (I2C, SPI, UART) are missing mandatory clock definitions.
- [Low] Missing `#address-cells` and `#size-cells` in all QUPv3 `spi` controller nodes.
--

--- Patch [1]: [PATCH v8 1/6] arm64: dts: qcom: Add device tree for Nord SoC series ---
commit dc243dd9ae24ddeada4cb82c2d839d010c16b477
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 file (nord.dtsi) for the Nord
SoC series. It describes core hardware components like CPU clusters, memory,
thermal zones, and QUPv3 serial engines.

> diff --git a/arch/arm64/boot/dts/qcom/nord.dtsi b/arch/arm64/boot/dts/qcom/nord.dtsi
> new file mode 100644
> index 0000000000000..117bcc2c88377
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/nord.dtsi

[ ... ]

> +		pdp0_p2a: scmi-shmem@87608000 {
> +			compatible = "arm,scmi-shmem";
> +			reg = <0x0 0x87608000 0x0 0x80>;
> +			no-map;
> +		};
> +
> +		pdp0_a2p: scmi-shmem@87608180 {
> +			compatible = "arm,scmi-shmem";
> +			reg = <0x0 0x87608180 0x0 0x80>;
> +			no-map;
> +		};

[Severity: High]
Do these sub-page no-map regions cause cache attribute aliasing?

The pdp0_p2a and pdp0_a2p regions only cover 256 bytes total within the
4KB physical page starting at 0x87608000. Because the rest of the page is
not reserved with no-map, it appears the kernel will map the entire 4KB
page as Normal Cacheable memory in the direct map, while the SCMI driver
will map the 256 bytes as Device/Non-cacheable memory.

[ ... ]

> +	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: Medium]
Will the QUPv3 drivers fail to probe because the clocks and clock-names
properties are missing from the wrapper nodes and child serial engines?

[ ... ]

> +			spi14: spi@880000 {
> +				compatible = "qcom,geni-spi";
> +				reg = <0x0 0x00880000 0x0 0x4000>;
> +				interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
> +
> +				status = "disabled";
> +			};

[Severity: Low]
Does this spi controller node (and the other spi nodes) need #address-cells
and #size-cells properties to allow child devices to parse their addresses
correctly?

[ ... ]

> +		cpu-0-0-0-thermal {
> +			polling-delay-passive = <0>;
> +			polling-delay = <0>;
> +			thermal-sensors = <&tsens0 1>;
> +
> +			trips {
> +				trip-point0 {
> +					temperature = <105000>;
> +					hysteresis = <10000>;
> +					type = "passive";
> +				};
> +
> +				trip-point1 {
> +					temperature = <125000>;
> +					hysteresis = <10000>;
> +					type = "passive";
> +				};
> +			};
> +		};

[Severity: High]
Should these thermal zones include a trip point configured for system shutdown?

Because the highest trip point is set to passive, it looks like the kernel
will never perform an orderly shutdown, leaving the system to rely entirely
on hardware thermal resets if temperatures continue to rise.

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