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

[Andy Shevchenko <andriy.shevchenko@intel.com>]

On Fri, Oct 02, 2026 at 08:47:10AM -0500, Frank Li wrote:
> On Fri, Oct 02, 2026 at 11:43:17AM +0100, Nuno Sá wrote:
> > On Mon, Sep 21, 2026 at 11:12:35AM -0500, Frank Li wrote:
> > > 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.
> >
> > So I was aboutto start on this again and I just realized
> > drivers/dma/dmaengine.h already exists today so nothing to do on this
> > series.
> 
> I just find it and start some cleanup/move work.
> 
> > I mean I could remove the consumer include on the dmaengine
> > drivers that I'm touching but not really on scope and super important
> > IMO. So, for the consumer side, should I just go to the first approach
> > where all the bus_width API goes into include/linux/dmaengine.h or
> > should I keep:
> >
> > include/linux/engine/types.h
> > include/linux/engine/widthmask.h
> >
> > And have a better separation on the consumer side? Or maybe changing
> > s/engine/consumer/ on the above paths?
> 
> I go through v3 thread, Andy just said split to new type.h, but not have
> provided reason.
> 
> I am planning move provide API and data structure to driver/dma/dmaengine.h
> 
> include/linux/dmaengine.h will keep consume only defination and API.
> 
> why still need types.h?

The idea was to rectify the messed up dependencies. Without split of types we
will need to have bitmap.h (IIRC the initial idea of the split was that) only
where it's indeed required. Besides bitmap.h there are might be more headers
that "include half of the world" which should be avoided in every header file.

-- 
With Best Regards,
Andy Shevchenko