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

+Cc: Arnd — what's your opinion about dmaengine.h case (see below for the details)?

On Wed, Aug 12, 2026 at 01:59:59PM +0100, Nuno Sá wrote:
> On Wed, Aug 12, 2026 at 01:18:41PM +0100, Nuno Sá wrote:
> > On Wed, Aug 12, 2026 at 12:48:48PM +0300, Andy Shevchenko wrote:
> > > On Wed, Aug 12, 2026 at 10:08:34AM +0100, Nuno Sá wrote:
> > > > On Tue, Aug 11, 2026 at 11:28:04PM +0530, Vinod Koul wrote:

...

> > > > Just remembered that bitmap.h is already included in dmaengine.h anyways. bitops.h
> > > > is because of __set/clear_bit().
> > > 
> > > Oh my gosh, true! bitmap.h implies all bit ops, so no need then a new header.
> > > Indeed the whole hell is due to dma_cap_zero(). So, while your patch won't
> > > change the current state, in lieu of the said previously I would like to have
> > > a split, but since dma_cap_zero() is used almost everywhere, perhaps make
> > > __dma_cap_zero() an exported function then? This, of course, can be done later
> > > but if we start from the more mess, it will be harder to untangle, so I still
> > > think the separate header is a way to go. And perhaps these capabilities also
> > > can be split to dmaengine-capmask.h (with a fallback inclusion in dmaengine.h)
> > > so in the future we can only include it when it's needed.
> > 
> > Yeps dmaengine-capmask.h would make sense to me but as I said, I really
> > don't have the bandwidth for that!
> > 
> > > Looking into the structure of the include/linux/dma* I even would think of
> > > something like include/linux/dma/engine/*.h with include/linux/dmaengine.h
> > > to collect (for backward compatibility), where the first citizen may be
> > > your API, followed by split capmask.h.
> > 
> > Ok. So what you have in mind is something like?
> > 
> > <include/linux/dma/engine/buswidth.h>
> > 	#include <linux/bitmap.h>

> > 	#include <linux/dmaengine.h>

Not really this one,

For a bare start to have something like

dmaengine.h:
  include dma/engine/capmask.h
  include dma/engine/types.h

so the latter (types.h) will have the basic minimum that is necessary
for capmask.h and (future) widthmask.h.

> I mean, one way I can see to avoid the above include is to come up with
> a new type like dma_cap_mask_t. Something dma_buswidth_mask_t...

Works for me as well, and we can put it in

  include dma/engine/widthmask.h

but this time without back include into linux/dmaengine.h.

> > And have all the inline helpers in there.
> > 
> > I can go with the above for v3, yes! But note one thing:
> > 
> > enum dma_slave_buswidth
> > DECLARE_DMA_BUS_WIDTHS()
> > 
> > will still be part of dmaengine.h and what I could do as follow up is to
> > move the above to something like
> > 
> > <include/linux/dma/engine/buswidth-types.h> or maybe just have a generic
> > <include/linux/dma/engine/types.h>

Yes, the second one.

> > Generic might make more sense given that we move around 7 typedefs in
> > dmaengine.h but I'm not so sure about the enums.

If enums are coupled with types, then they should be there, otherwise we also
have a concept of defs.h (but not as distributed as types.h).

> > Then, we can also do the split for capmask.h as you said. I can do the
> > dma part of things I can't just commit to change all users in the kernel
> > for the new headers :)

But it's not needed, everything except brand new APIs will be back included
into dmaengine.h. Old users will work, new users will be encouraged to use
exactly what they need.

> > (Ok, moving the buswidth types into a new header might make sense in
> > this series - if we agree with that direction).

-- 
With Best Regards,
Andy Shevchenko