Re: [PATCH 1/3] spi: dt-bindings: cdns,xspi: Add DMA properties

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] spi: dt-bindings: cdns,xspi: misuse of dmas property for
  memcpy channel
--

commit bdaf74eae564e5ab96700c90ad51b7fb6c7c0da6
Author: Jisheng Zhang <jszhang@kernel.org>

spi: dt-bindings: cdns,xspi: Add DMA properties

This commit adds dmas and dma-names properties to the Cadence XSPI
device tree binding to describe a DMA memcpy channel.

> diff --git a/Documentation/devicetree/bindings/spi/cdns,xspi.yaml b/Documentation/devicetree/bindings/spi/cdns,xspi.yaml
> index 38a5795589de2..b19c2e051e189 100644
> --- a/Documentation/devicetree/bindings/spi/cdns,xspi.yaml
> +++ b/Documentation/devicetree/bindings/spi/cdns,xspi.yaml
> @@ -40,6 +40,19 @@ properties:
>    interrupts:
>      maxItems: 1
>  
> +  dmas:
> +    maxItems: 1
> +    description: |
> +      Optional DMA memcpy channel for transfers between memory and the Slave
> +      DMA data port. The channel is shared by reads and writes.
> +
> +  dma-names:
> +    const: memcpy
> +
> +dependencies:
> +  dmas: [dma-names]
> +  dma-names: [dmas]

[Severity: Medium]
Should a software-triggered DMA_MEMCPY channel be described with dmas and
dma-names in the device tree binding?

The dmas property in dma-common.yaml describes hardware DMA request lines
routed between a peripheral and a DMA controller. The Cadence XSPI Slave
DMA data port is a memory-mapped aperture driven by the controller's SDMA
trigger interrupt and memory-to-memory DMA_MEMCPY transfers, with no
hardware DMA request signal.

Requesting this channel through devm_dma_request_chan(dev, "memcpy") goes
through of_dma_request_slave_channel() and the DMA controller's
of_dma_xlate() callback, which expects hardware slave request specifiers
in #dma-cells and fails or requires fabricated specifiers on controllers
that validate slave request IDs or only expose DMA_MEMCPY channels.

Other drivers with memory-mapped ports and DMA_MEMCPY transfers, including
the sibling Cadence HPNFC driver in
drivers/mtd/nand/raw/cadence-nand-controller.c and
drivers/spi/spi-cadence-quadspi.c, allocate the channel in the driver via
dma_request_chan_by_mask() with DMA_MEMCPY instead of adding dmas =
"memcpy" to the binding. If a platform does wire a hardware DMA request
line to the SPI controller, spi-controller.yaml names a shared channel
"rx-tx" rather than "memcpy".

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261107072044.17574-1-jszhang@kernel.org?part=1