Re: [PATCH v4 01/10] dmaengine: Move enum dma_slave_buswidth to a new header

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

On Tue, Oct 06, 2026 at 07:36:06AM +0100, Nuno Sá wrote:
> On Sat, 2026-10-03 at 19:59 -0500, Frank Li wrote:
...
> >
> > There are already include bitmap.h, and use
> >
> > typedef struct { DECLARE_BITMAP(bits, DMA_TX_TYPE_END); } dma_cap_mask_t;
> >
> > Suppose all DMA Engine consumer will use it to do some check. So I think
> > needn't split it as indivial version.
>
> Are we sure all consumers are making use of dma_cap_mask?

Some legacy user check it. Supposed needn't check it after get channel.
I am working new API to check it to avoid direct access it.

> In fact the only function
> depending on bitmap.h is the one clearing the cap_mask. But stepping a bit back,
> bitmap.h was the original proposal from Andy so the idea was to have the new
> widthmask (this one indeed heavily uses bitmaps) already as a split. And with it,
> came types.h given that the DMA enum needs to be used from both consumers and
> providers.

Supposed provider is super set, which can include consume part.

> And note that consumers might want the header without actually needing the
> bus width API so the separation kind of made sense to me.
> Then, as a follow up the idea was to also split the cap_mask API into it's own header
> with a backing include in the main consumer header.
>
> So if we all agree with the above, I guess the current series does not really has to
> change. I see 3 ways:
>
> * Just go back some versions before and have all of it in dmaengine.h
> * The current form
> * s/engine/consumer on the current proposal include/linux/dma/engine/*

I think we can put include/linux/dmaengine.h now. The split/move need more
work. I already sent some patches.

Frank

>
> - Nuno Sá
>
> >
> > Frank
> >
> > > where it's indeed required. Besides bitmap.h there are might be more headers
> > > that "include half of the world" which should be avoided in every header file.
> > >
> > > --
> > > With Best Regards,
> > > Andy Shevchenko
> > >
> > >