Re: [PATCH v2 1/2] arm64: dts: qcom: nord: add GPI DMA controller nodes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] dts: scrambled interrupts array in gpi_dma0 causes DMA timeouts
- [Low] dts: undocumented compatible string 'qcom,nord-gpi-dma'
--

commit 707c09883742930c1c91a2275e454e20b950b1e1
Author: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

    arm64: dts: qcom: nord: add GPI DMA controller nodes

This commit adds GPI DMA controller nodes for all three QUPv3 engines in the
qcom nord device tree.

> diff --git a/arch/arm64/boot/dts/qcom/nord.dtsi b/arch/arm64/boot/dts/qcom/nord.dtsi
> index e0496fd40c308..9f4e0e1498c32 100644
> --- a/arch/arm64/boot/dts/qcom/nord.dtsi
> +++ b/arch/arm64/boot/dts/qcom/nord.dtsi
[ ... ]
> @@ -909,6 +910,28 @@ soc: soc@0 {
>  		dma-ranges = <0 0 0 0 0x10 0>;
>  		ranges = <0 0 0 0 0x10 0>;
>  
> +		gpi_dma2: dma-controller@800000 {
> +			compatible = "qcom,nord-gpi-dma", "qcom,sm6350-gpi-dma";

[Severity: Low]
Does this new compatible string lack documentation in the dt-bindings?

Running dtbs_check validation will fail because the compatible string
"qcom,nord-gpi-dma" is not defined in
Documentation/devicetree/bindings/dma/qcom,gpi.yaml.

This only affects build/validation tooling, not runtime behavior, as the
kernel will successfully match on the fallback string "qcom,sm6350-gpi-dma".

> +			reg = <0x0 0x00800000 0x0 0x60000>;
> +			#dma-cells = <3>;
[ ... ]
> @@ -1107,6 +1130,28 @@ uart20: serial@898000 {
>  			};
>  		};
>  
> +		gpi_dma0: dma-controller@900000 {
> +			compatible = "qcom,nord-gpi-dma", "qcom,sm6350-gpi-dma";

[Severity: Low]
Is "qcom,nord-gpi-dma" documented in the dt-bindings?

Like the gpi_dma2 node above, dtbs_check validation will fail because this
new compatible string is not defined in
Documentation/devicetree/bindings/dma/qcom,gpi.yaml.

> +			reg = <0x0 0x00900000 0x0 0x60000>;
> +			#dma-cells = <3>;
> +			interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>,

[Severity: High]
Does this unordered list of interrupts break the IRQ-to-GPII instance mapping
in the driver?

The interrupts array for gpi_dma0 interleaves IRQs from distinct blocks
(116-121 and 205-223). The GPI DMA driver in drivers/dma/qcom/gpi.c maps
each hardware GPII instance to the corresponding interrupt in the DT array
using platform_get_irq().

Because of the scrambling, the driver will request the wrong IRQ lines for
its active GPII instances (e.g., requesting IRQ 205 instead of 117 for
instance 1). This is a static hardware configuration error that
unconditionally breaks DMA functionality for this block on boot, as
transfers on QUPv3_0 peripherals will time out because completion interrupts
are routed to the wrong handlers.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260921-nord-gpi-dts-v2-0-4f297c983b94@oss.qualcomm.com?part=1