Re: [PATCH v4 03/10] dmaengine: dma-axi-dmac: Use bus width capability helpers

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Incorrect assignment of byte alignment to log2 alignment shift field (copy_align)
--

commit 0bfee90ef28dc903c00f72e9bd5881ba53dcd68f
Author: Nuno Sá <nuno.sa@analog.com>

dmaengine: dma-axi-dmac: Use bus width capability helpers

This commit updates the dma-axi-dmac driver to use the new
dma_bus_width_set() helper instead of open-coding the legacy BIT() mask for
source and destination bus widths. It also updates the channel width members
to use the proper enum dma_slave_buswidth type, allowing the driver to
express widths of 32 bytes and above.

> diff --git a/drivers/dma/dma-axi-dmac.c b/drivers/dma/dma-axi-dmac.c
> --- a/drivers/dma/dma-axi-dmac.c
> +++ b/drivers/dma/dma-axi-dmac.c
[ ... ]
> @@ -1262,8 +1263,13 @@ static int axi_dmac_probe(struct platform_device *pdev)
>  	dma_dev->device_terminate_all = axi_dmac_terminate_all;
>  	dma_dev->device_synchronize = axi_dmac_synchronize;
>  	dma_dev->dev = &pdev->dev;
> -	dma_dev->src_addr_widths = BIT(dmac->chan.src_width);
> -	dma_dev->dst_addr_widths = BIT(dmac->chan.dest_width);
> +	ret = dma_bus_width_set(dma_dev->src_bus_widths, dmac->chan.src_width);
> +	if (ret)
> +		return ret;
> +
> +	ret = dma_bus_width_set(dma_dev->dst_bus_widths, dmac->chan.dest_width);
> +	if (ret)
> +		return ret;
>  	dma_dev->directions = BIT(dmac->chan.direction);
>  	dma_dev->residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
>  	dma_dev->max_sg_burst = 31; /* 31 SGs maximum in one burst */

[Severity: High]
This isn't a bug introduced by this patch, but while evaluating bus width
capabilities in axi_dmac_probe(), is there an existing issue with how
copy_align is assigned further down in the function?

Looking at axi_dmac_probe(), we have this assignment:

	dma_dev->copy_align = (dmac->chan.address_align_mask + 1);

The copy_align field requires an enum dmaengine_alignment, which represents
the base-2 logarithm of the byte alignment (e.g. DMAENGINE_ALIGN_8_BYTES = 3).

By assigning it the exact byte count instead of the log2 shift, any
subsystem evaluating 1 << copy_align will compute excessively large
alignment constraints (for example, 1 << 8 = 256 bytes instead of 8).

For a 32-byte bus width, could this lead to undefined behavior in C since
the shift count equals or exceeds the width of the default integer type?
This might cause zero alignment enforcement and subsequent hardware exceptions
when unaligned buffers are passed to the DMA controller.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260911-dmaengine-support-wider-dma-masks-v4-0-72b8fd4cc78e@analog.com?part=3