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

["Nuno Sá" <nuno.sa@analog.com>]

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>

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>

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

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 :)

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

- Nuno Sá

> -- 
> With Best Regards,
> Andy Shevchenko
> 
>