Re: [PATCH v2 1/9] dmaengine: Support bus widths of 32 bytes and above

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Inconsistent state between legacy `u32` capabilities and new bus width bitmaps due to legacy `device_caps()` modifications.
--

--- Patch [1]: [PATCH v2 1/9] dmaengine: Support bus widths of 32 bytes and above ---
commit cae7966e8491d2d3566b285f48d250a84ed67596
Author: Nuno Sá <[email protected]>

dmaengine: Support bus widths of 32 bytes and above

This commit introduces bitmap-based bus width capabilities to support
bus widths of 32 bytes and above, which exceed the capacity of the
legacy u32 masks. Legacy u32 fields are kept alongside the new bitmaps
to allow incremental conversion of drivers.

> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -593,7 +593,25 @@ int dma_get_slave_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
>  		return -ENXIO;
>  
>  	caps->src_addr_widths = device->src_addr_widths;
> +	if (bitmap_empty(device->src_bus_widths, DMA_SLAVE_BUSWIDTH_MAX)) {
> +		bitmap_zero(caps->src_bus_widths, DMA_SLAVE_BUSWIDTH_MAX);
> +		bitmap_from_arr32(caps->src_bus_widths,
> +				  &device->src_addr_widths, 32);
> +	} else {
> +		bitmap_copy(caps->src_bus_widths, device->src_bus_widths,
> +			    DMA_SLAVE_BUSWIDTH_MAX);
> +	}
> +
>  	caps->dst_addr_widths = device->dst_addr_widths;
> +	if (bitmap_empty(device->dst_bus_widths, DMA_SLAVE_BUSWIDTH_MAX)) {
> +		bitmap_zero(caps->dst_bus_widths, DMA_SLAVE_BUSWIDTH_MAX);
> +		bitmap_from_arr32(caps->dst_bus_widths,
> +				  &device->dst_addr_widths, 32);
> +	} else {
> +		bitmap_copy(caps->dst_bus_widths, device->dst_bus_widths,
> +			    DMA_SLAVE_BUSWIDTH_MAX);
> +	}
> +

[Severity: Medium]
Does this sequence leave the new bitmaps out of sync if a legacy driver
modifies the capabilities dynamically?

Later in dma_get_slave_caps(), the device_caps callback is invoked:

    if (device->device_caps)
        device->device_caps(chan, caps);

Some legacy drivers restrict bus widths dynamically in this callback by
modifying the legacy u32 fields directly. For example, in stm32-dma3.c:

stm32_dma3_caps() {
    ...
    caps->src_addr_widths &= ~BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
}

Because the new bitmaps are populated from the static device capabilities
before the callback is executed, won't these dynamic restrictions be missed
in the new bitmap fields?

When consumers migrate to the new API, could they see unsupported bus widths
as available, potentially leading to invalid configurations?

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