Re: [PATCH v2 8/9] spi: dw: Use dma_slave_caps bus width helpers

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] `dw_spi_can_dma()` evaluates DMA capabilities using a stale or uninitialized `dws->n_bytes` value, which can incorrectly accept or reject DMA mapping.
--

--- Patch [8]: [PATCH v2 8/9] spi: dw: Use dma_slave_caps bus width helpers ---
commit 4458885866ffec3718df2694d83959e2e55d8975
Author: Nuno Sá <[email protected]>

spi: dw: Use dma_slave_caps bus width helpers
    
Store the common TX destination and RX source bus widths in a driver-owned
DMA bus width bitmap and populate it through the dma_slave_caps helper.

> diff --git a/drivers/spi/spi-dw-dma.c b/drivers/spi/spi-dw-dma.c
> index fe726b9b1780d..2e23ead4a94f9 100644
> --- a/drivers/spi/spi-dw-dma.c
> +++ b/drivers/spi/spi-dw-dma.c
[ ... ]
> @@ -253,7 +253,7 @@ static bool dw_spi_can_dma(struct spi_controller *ctlr,
>  
>  	dma_bus_width = dw_spi_dma_convert_width(dws->n_bytes);
>  
> -	return dws->dma_addr_widths & BIT(dma_bus_width);
> +	return test_bit(dma_bus_width, dws->dma_bus_widths);
>  }

[Severity: High]
This is a pre-existing issue, but does evaluating the DMA capabilities here
rely on a stale or uninitialized value for dws->n_bytes?

The SPI core calls spi_map_msg(), which invokes the can_dma callback for
each transfer before any transfer_one callbacks are executed. However, it
looks like dws->n_bytes is not updated based on the current transfer's
bits_per_word until later:

drivers/spi/spi-dw-core.c:dw_spi_transfer_one() {
    ...
    dws->n_bytes = spi_bpw_to_bytes(transfer->bits_per_word);
    ...
}

Because of this sequence, dw_spi_can_dma() appears to use the n_bytes value
left over from the last transfer of the previous message (or 0 for the first
message).

If the previous message used a supported bus width (e.g., 1 byte) but the
current message uses an unsupported one (e.g., 4 bytes), will
dw_spi_can_dma() incorrectly return true? This seems like it could force an
unsupported DMA setup and fail the transfer entirely, rather than gracefully
falling back to PIO mode.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260810-dmaengine-support-wider-dma-masks-v2-0-1f7b798d035f@analog.com?part=8