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

["Nuno Sá" <noname.nuno@gmail.com>]

On Sat, 2026-10-03 at 19:59 -0500, Frank Li wrote:
> On Sat, Oct 03, 2026 at 05:52:48PM +0300, Andy Shevchenko wrote:
> > 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
> 
> There are already include bitmap.h, and use
> 
> typedef struct { DECLARE_BITMAP(bits, DMA_TX_TYPE_END); } dma_cap_mask_t;
> 
> Suppose all DMA Engine consumer will use it to do some check. So I think
> needn't split it as indivial version.

Are we sure all consumers are making use of dma_cap_mask? In fact the only function
depending on bitmap.h is the one clearing the cap_mask. But stepping a bit back,
bitmap.h was the original proposal from Andy so the idea was to have the new
widthmask (this one indeed heavily uses bitmaps) already as a split. And with it,
came types.h given that the DMA enum needs to be used from both consumers and
providers. And note that consumers might want the header without actually needing the
bus width API so the separation kind of made sense to me.
Then, as a follow up the idea was to also split the cap_mask API into it's own header
with a backing include in the main consumer header.

So if we all agree with the above, I guess the current series does not really has to
change. I see 3 ways:

* Just go back some versions before and have all of it in dmaengine.h
* The current form
* s/engine/consumer on the current proposal include/linux/dma/engine/*

- Nuno Sá

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