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

On Sat, Aug 01, 2026 at 03:46:17AM +0100, Jonathan Cameron wrote:
> On Sat, 1 Aug 2026 03:42:22 +0100
> Jonathan Cameron <[email protected]> wrote:
> 
> > On Thu, 30 Jul 2026 14:16:30 -0500
> > Frank Li <[email protected]> wrote:
> > 
> > > On Thu, Jul 30, 2026 at 03:23:08PM +0100, Nuno Sá via B4 Relay wrote:  
> > > > [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > > >
> > > > From: Nuno Sá <[email protected]>
> > > >
> > > > The src_addr_widths and dst_addr_widths capability masks encode each
> > > > supported width as a bit whose position equals the corresponding
> > > > enum dma_slave_buswidth value (e.g. DMA_SLAVE_BUSWIDTH_4_BYTES sets bit
> > > > 4). As these masks are plain u32, widths of 32 bytes and above
> > > > (DMA_SLAVE_BUSWIDTH_32/64/128_BYTES map to bits 32, 64 and 128) cannot
> > > > be represented at all.
> > > >
> > > > Introduce bitmap-based bus width capabilities that span the full enum
> > > > range. To allow DMA controller producers to be converted incrementally,
> > > > keep the legacy dma_device u32 fields alongside the new bitmaps:
> > > > producers using the new helpers populate the bitmap and mirror the low
> > > > 32 bits back into the legacy field, while dma_get_slave_caps() folds a
> > > > legacy-only producer's u32 into the returned bitmap.
> > > >
> > > > Add helpers for producers and consumers so users do not need to depend
> > > > on the bitmap layout directly. Once the remaining producers are
> > > > converted, the legacy dma_device u32 fields can be dropped.
> > > >
> > > > Signed-off-by: Nuno Sá <[email protected]>
> > > > ---    
> > > 
> > > Reviewed-by: Frank Li <[email protected]>  
> > https://sashiko.dev/#/patchset/20260730-dmaengine-support-wider-dma-masks-v1-0-3732f1f9d9ca%40analog.com 
> > has a comment on this that smells plausible at least.
> > Looks like the stm32 driver modifies dst_bus_widths in it's device_caps()
> > callback.
> Reading on, you fix it later in series.
> 
> This is going to break bisection on that device, but not build
> so I guess maybe fair enough to do it in this sequence.

This is a bit tricky (with trying to keep things compatible throughout
the transition). But I think it should be fine because the current patch
keeps (or at least tries) the old addr_masks and even we then update the
stm controller we also act on both the new and old variables (so
consumers still work).

- Nuno Sá

> 
> J
> > 
> > Jonathan
> > 
>