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

[Frank Li]

On Mon, Sep 21, 2026 at 09:53:49AM +0100, Nuno Sá wrote:
> On Fri, Sep 18, 2026 at 11:33:41PM +0530, Vinod Koul wrote:
> > On 18-09-26, 09:39, Nuno Sá wrote:
> > > On Thu, Sep 17, 2026 at 11:39:54PM +0530, Vinod Koul wrote:
> > > > On 15-09-26, 12:04, Frank Li wrote:
> > > > > On Tue, Sep 15, 2026 at 09:50:22PM +0530, Vinod Koul wrote:
> > > > > > On 15-09-26, 21:22, Vinod Koul wrote:
> > > >
> > > > > > > > Traditional naming would be
> > > > > > > > dma/engine/provider.h
> > > > > > > > dma/engine/consumer.h
> > > > > > >
> > > > > > > consumer and provider and good names.. I would retain the full dmaengine
> > > > > > > everywhere please. dma causes confusion already!
> > > > > >
> > > > > > Thinking about it again, drivers/dma/dmaengine.h should be the provider
> > > > >
> > > > > There some dmaengine code outside drivers/dma directory, like
> > > > > drivers/crypto/ccp/ccp-dmaengine.c
> > > >
> > > > They chose to be outside, their choice... They need to be updated as
> > > > well to point to ../../dma/dmaengine.h :-)
> > >
> > > I tend to agree with Andy but anyways. I feel this is going a bit out of
> > > scope now. So what we have now in the series is:
> > >
> > >
> > > - include/linux/dmaengine.h (without enum dma_slave_buswidth)
> > > - include/linux/dma/types.h (with enum dma_slave_buswidth and new
> > >   dma_buswidth_t type) - A future one would be dma_cap_mask_t and we could
> > >   drop bitmap.h from dmaengine.h
> > > - include/linux/dma/widthmask.h - The new bitmap based API for bus_width
> > >
> > > I kind like the separation (and the whole point was to avoid bitmap.h in
> > > the main dmaengine.h API) but tbh I'm not sure if a consumer driver
> > > will ever use dma/widthmask.h without needing the consumer API. But
> > > to sum things up, what do you suggest for vÛE?
> > >
> > > * include/linux/dmaengine.h as the consumer API and includes the new
> > > the widthmask API
> > > * provider/private goes to drivers/dma/dmaengine.h and just includes
> > > include/linux/dmaengine.h as the starting point?
> > >
> > > Let me know how do you want things for v5
> >
> > Yes lets talk about dma_slave_buswidth, it is client type. This is
> > configured by users to set the width of peripheral.
> > So this needs to be in the include/linux/dmaengine.h
> >
>
> Agreed! But providers also need to set the allowed bus mask. And I'm
> just not sure they need to include/consume all of the consumer API.
> Also, it's common to allow the provider API to be widely used throughout
> the kernel (but I agree that could be even harder to get done - if we
> want to make some stuff really private - but I guess that could be done
> in a second step or more incrementally). We do also have some subfolders
> in `drivers/dma` which means we'll need the odd "../dmaengine.h" relative
> include which I do not love tbh (on top of the crypto stuff).
>
> I really think something like the below would be more appropriate (if we
> just want the provider/consumer API without further splitting like the
> types.h and widthmak.h in this version):
>
> include/linux/dmaengine.h - provider API (as of today)
> include/linux/dmaengine-consumer.h
>
> But anyways, if you or Frank do not object in the next few days, I'll
> take the above approach suggested by Vinod:
>
> drivers/dma/dmaengine.h - provider
> include/linux/dmaengine.h - consumer

It think it is fine.

Frank

>
> - Nuno Sá
>
> > --
> > ~Vinod