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

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

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

- Nuno Sá

> -- 
> ~Vinod