Re: [PATCH v2 5/5] arm64: dts: microchip: lan969x: add QSPI nodes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `qspi2` node is missing `dmas` and `dma-names` properties (unlike `qspi0`), which degrades performance to PIO mode and causes the atmel-quadspi driver to log a spurious error during probe.
--

--- Patch [5]: [PATCH v2 5/5] arm64: dts: microchip: lan969x: add QSPI nodes ---
commit 297e92dccc7e525621a995eb1402956ad591b3bf
Author: Robert Marko <robert.marko@sartura.hr>

arm64: dts: microchip: lan969x: add QSPI nodes

This commit adds device tree nodes for both QSPI controllers on the Microchip
LAN969x SoC. It configures base addresses, interrupts, and clocks for the
controllers.

> diff --git a/arch/arm64/boot/dts/microchip/lan9691.dtsi b/arch/arm64/boot/dts/microchip/lan9691.dtsi
> index ed997d87dd09f..a8541c6a098d1 100644
> --- a/arch/arm64/boot/dts/microchip/lan9691.dtsi
> +++ b/arch/arm64/boot/dts/microchip/lan9691.dtsi

[ ... ]

> @@ -396,6 +396,39 @@ clks: clock-controller@e00c00b4 {
>  			clock-names = "cpu", "ddr", "sys";
>  		};
>  
> +		qspi0: spi@e0804000 {
> +			compatible = "microchip,lan9691-qspi";

[ ... ]

> +			dmas = <&dma AT91_XDMAC_DT_PERID(1)>,
> +			       <&dma AT91_XDMAC_DT_PERID(0)>;
> +			dma-names = "tx", "rx";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			status = "disabled";
> +		};
> +
> +		qspi2: spi@e0834000 {
> +			compatible = "microchip,lan9691-qspi";
> +			reg = <0xe0834000 0x00000100>,
> +			      <0x30000000 0x04000000>;
> +			reg-names = "qspi_base", "qspi_mmap";
> +			interrupts = <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&fabric_clk>, <&clks GCK_ID_QSPI2>;
> +			clock-names = "pclk", "gclk";
> +			assigned-clocks = <&clks GCK_ID_QSPI2>;
> +			assigned-clock-rates = <100000000>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			status = "disabled";
> +		};

[Severity: Medium]
Is it intentional that qspi2 is missing the dmas and dma-names properties?

During probe, the atmel-quadspi driver unconditionally checks for dma since
aq->caps->has_dma is true for LAN969x compatible strings, and then calls
atmel_qspi_dma_init().

Without the dmas property present here, devm_dma_request_chan() returns
-ENODEV. The driver handles this with dev_err_probe(), which emits a
kernel error log ('error -ENODEV: RX DMA channel is not available') because
it is not -EPROBE_DEFER.

The controller will then fall back to pio mode, degrading performance.

If the hardware supports dma for qspi2, should these properties be added?
If it does not, should the driver be updated to avoid unconditionally setting
has_dma to true for all instances?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709112006.390742-1-robert.marko@sartura.hr?part=5