Re: [PATCH 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:
- [High] Legacy `device_caps()` callbacks cause desynchronization between t=
he legacy `u32` capability masks and the newly introduced bitmap fields in =
`struct dma_slave_caps`, leading to unsupported bus widths being falsely ad=
vertised to consumers.
--

--- Patch [1]: [PATCH 1/9] dmaengine: Support bus widths of 32 bytes and ab=
ove ---
commit 2d5a426ace9eaa0310bd634be5edc8e4ed522c24
Author: Nuno S=C3=A1 <[email protected]>

dmaengine: Support bus widths of 32 bytes and above

Introduces bitmap-based bus width capabilities that span the full enum
range to support widths of 32 bytes and above. Retains the legacy u32
fields alongside the new bitmaps to allow incremental conversion of
producers.

> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index 9049171df8578..7be23ba769d0d 100644
> --- 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)
[ ... ]
>  	caps->dst_addr_widths =3D 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);
> +	}
> +
>  	caps->directions =3D device->directions;
>  	caps->min_burst =3D device->min_burst;
>  	caps->max_burst =3D device->max_burst;

[Severity: High]
Does this setup cause a desynchronization between the new bitmaps and the
legacy u32 fields after device_caps() is invoked?

Looking at the end of dma_get_slave_caps() in drivers/dma/dmaengine.c:

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

	return 0;

Legacy drivers dynamically modify the u32 fields in their device_caps()
callback. For example, stm32_dma3_caps() in drivers/dma/stm32/stm32-dma3.c
modifies the capabilities:

	caps->src_addr_widths &=3D ~BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);

Since the new bitmaps are initialized before device_caps() is called, and
there is no re-synchronization of the legacy u32 fields back to the bitmaps
after it returns, won't consumers querying capabilities using new helpers
like dma_slave_caps_intersect_widths() read the unmodified, stale bitmaps?

Could this result in consumer drivers configuring a DMA transfer with an
unsupported bus width?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260730-dmaengine-=
[email protected]?part=3D1