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

[Frank Li <Frank.li@oss.nxp.com>]

On Mon, Oct 12, 2026 at 11:47:20AM +0100, Nuno Sá wrote:
> On Fri, Oct 09, 2026 at 09:45:06PM -0500, Frank Li wrote:
> > On Fri, Oct 09, 2026 at 04:52:53PM +0100, Nuno Sá wrote:
> > > 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, through a new dma_buswidth_mask_t type modeled after
> > > dma_cap_mask_t. To allow DMA controller drivers to be converted
> > > incrementally, the legacy dma_device u32 fields are kept alongside the
> > > new masks and the core folds a legacy-only driver's u32 into the mask
> > > when the device is registered, so consumers only ever have to look at
> > > the mask.
> > >
> > > The fold is bidirectional while both representations coexist. A driver
> > > that only fills in the legacy u32 gets its mask derived from it, so the
> > > consumers already converted see it. A driver that only fills in the mask
> > > gets its legacy u32 derived from the mask, so the consumers not
> > > converted yet, which read the legacy dma_slave_caps fields, keep working.
> > >
> > > On top of that, dma_get_slave_caps() derives the legacy dma_slave_caps
> > > masks from the new ones when a device_caps() callback adjusted them, so
> > > that a converted controller narrowing its per-channel capabilities is
> > > still seen by the consumers not converted yet, while a driver adjusting
> > > the legacy masks directly keeps working.
> > >
> > > Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> > >
> > > ---
> > >
> > > Andy, did not take your tag given that you're the one asking for the
> > > split and since we ended up not doing it, not sure if the tag is
> > > to be kept :)
> > > ---
> > >  drivers/dma/dmaengine.c   |  51 +++++++++++-
> > >  include/linux/dmaengine.h | 208 +++++++++++++++++++++++++++++++++++++++++++---
> > >  2 files changed, 246 insertions(+), 13 deletions(-)
> > >
> > ...
> > >
> > >  	/* note: this only matters in the
> > > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> > > index 71cde09ff240..eb68eea840b5 100644
> > > --- a/include/linux/dmaengine.h
> > > +++ b/include/linux/dmaengine.h
> > > @@ -427,8 +427,179 @@ enum dma_slave_buswidth {
> > >  	DMA_SLAVE_BUSWIDTH_32_BYTES = 32,
> > >  	DMA_SLAVE_BUSWIDTH_64_BYTES = 64,
> > >  	DMA_SLAVE_BUSWIDTH_128_BYTES = 128,
> > > +	DMA_SLAVE_BUSWIDTH_MAX
> > >  };
> > >
> > ...
> > > +/**
> > > + * dma_bus_width_min - get the smallest bus width of a bus width mask
> > > + * @mask: bus width mask
> > > + *
> > > + * Return: the smallest bus width set in @mask, or
> > > + * %DMA_SLAVE_BUSWIDTH_UNDEFINED if @mask is empty.
> > > + */
> > > +#define dma_bus_width_min(mask) __dma_bus_width_min(&(mask))
> > > +
> >
> > We are working on make dma_device private. New API avoid direct use
> > dma_device field.
> >
> > pass down dma_chan point, dma engine handle everything in core part.
>
> Not sure I follow the above. All the API's work directly on
> dma_buswidth_mask_t and never touch dma_device. Now, consumers should
> use this API through struct dma_slave_caps while provider's
> (drivers/dma) should be able to use the private struct?
>
> Other thing that came to mind that I can do in v6 is that APIs that
> change the mask like:
>
> dma_bus_width_clear()
> dma_bus_width_set_many()
> dma_bus_width_set()
>
> Should be safely made private? I mean my expectation is that only
> controllers know (can) act of the bitmap so don't think there's any
> usecase where it makes sense to have API's like the above on the
> consumer side of things?

Sorry, I messed up. It is in dma_slave_config, which should be used by
consumer.

But all API should be prefix dmaengine_

Frank