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

[Nuno Sá]

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

Thx!
- Nuno Sá

> 
> -- 
> ~Vinod