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

[Frank Li <Frank.li@oss.nxp.com>]

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.

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