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

[Nuno Sá]

On Tue, Sep 15, 2026 at 05:53:26PM +0300, Andy Shevchenko 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.
> 
> Hmm... The whole split as is in this series is due to bitmap.h and the whole
> train wreck with headers we have. I haven't checked that particular enum, but
> if it's possible to gather it in one of provider.h/consumer.h at the end, then
> yes, we may name file accordingly from day 1.

Yeah, as I said to Frank that enum is used by both providers and
consumers so leaving it in types.h makes sense to me. I also realized
that the current series is relying on widthmask.h (or dmaengine.h to include
types.h - for the enum). Might be acceptable (and needed for legacy code
just including dmaengine.h) but I wonder if we should not explicitly include
types.h for new (or converted) code.

- Nuno Sá

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