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

[Nuno Sá]

On Thu, Sep 17, 2026 at 09:38:15AM -0500, Frank Li wrote:
> On Thu, Sep 17, 2026 at 11:49:46AM +0100, Nuno Sá wrote:
> > On Tue, Sep 15, 2026 at 09:37:44AM -0500, Frank Li wrote:
> > > On Tue, Sep 15, 2026 at 10:29:03AM +0300, Andy Shevchenko wrote:
> > > > On Mon, Sep 14, 2026 at 09:18:42AM -0500, Frank Li wrote:
> > > > > On Fri, Sep 11, 2026 at 06:25:36PM +0100, Nuno Sá wrote:
> > > > > > In preparation for the bitmap based bus width capabilities, move
> > > > > > enum dma_slave_buswidth out of linux/dmaengine.h into a new
> > > > > > include/linux/dma/engine/types.h.
> > > > > >
> > > > > > linux/dmaengine.h is included nearly everywhere, so growing it with the
> > > > > > new interface would make every one of its users pay for it. Keeping the
> > > > > > basic types in a separate header lets the new interface live next to it
> > > > > > without that cost. linux/dmaengine.h includes the new header, so its
> > > > > > users are unaffected.
> > > > > >
> > > > > > While at it, add the missing kernel-doc for the enum members. The block
> > > > > > already opened with /**, so kernel-doc expected every member to be
> > > > > > described and warned about each one of them. Describe the UNDEFINED case
> > > > > > in particular, as its meaning depends on where the value is used.
> > > >
> > > > ...
> > > >
> > > > > >  include/linux/dmaengine.h        | 20 +++-----------------
> > > > >
> > > > > I think it is good to split dmengine consumer and provider header files to
> > > > > hidden dmaengine's detail.
> > > >
> > > > It's indeed desirable change. but isn't it a bit out of scope of the series?
> > > > I suggest to do one step at a time. Would it work for you?
> > >
> > > Yes, but I hope the file name is finial expected file name. it is okay
> > > just move enum dma_slave_buswidth to there now.
> >
> > Hi Frank, if I understood you, you mean to have an engine.h as kind of a
> > consumer and have enum dma_slave_buswidth on it?
> 
> yes,
> 
> >
> > If so, note that enum is used both by consumers and providers so having
> > them in types kind of header makes sense to me. Kind of the same as with
> > the new widthmask header. It's used by both.
> 
> Yes, generally, provider include consumer's header files.
> 
> suppose detail dmaengine implement should be hidden in provider header
> files.
> 
> consumer is just subset by use provide APIs. It takes time to implement it
> but can start work from enum dma_slave_buswidth.

So widthmask.h remains as include/linux/engine/widthmask.h?
> 
> Just choose good filenames now, avoid rename letter.
> 
> ideally, As vnod said include/linux/dmaengine.h is consumer header file.
> drivers/dma/dmaegine.h as providers.
> 
> but some dmaengine driver outside drivers/dma/ directory.
> 
> Maybe we use
> 
> include/linux/dmaengine_consumer.h as start.  wait for vnod to comments.
> 

If the answer to the above is yes, then widthmask having to include
consumer.h for the enum does not make much sense to me.

So I feel like the more appropriate question is whether  enum
dma_slave_buswidth makes sense to be in a consumer.h file or in types.h
kind of file?

- Nuno Sá

> Frank
> 
> >
> > - Nuno Sá
> >
> > >
> > > Frank
> > >
> > > >
> > > > > suggest name
> > > > > 	dma/engine.h
> > > > >
> > > > > so we can start move more API to this files.
> > > > >
> > > > > after all user include this consumer header file,  old
> > > > > include/linux/dmaengine.h rename to include/linux/dmaengine-provider.h,
> > > > > which only include by dmaengine drivers.
> > > >
> > > > Traditional naming would be
> > > > dma/engine/provider.h
> > > > dma/engine/consumer.h
> > > >
> > > > --
> > > > With Best Regards,
> > > > Andy Shevchenko
> > > >
> > > >