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

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

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.

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.

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