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

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>

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...

- Nuno Sá

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