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

On Thu, Aug 13, 2026 at 09:30:59AM +0300, Andy Shevchenko wrote:
> +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

For my series I need dmaengine.h because the API relies on stuct dma_dev
and the slave_config which do belong to dmaengine.h. Solution is to have
the buswidth API depend on it's own type as suggested below. That way we
should be fine.

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

Good then! I somehow thought the expectation would be to convert
existing users!

- Nuno Sá

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