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.

Also, don't fully agree with the above. Take gpio and clk as an example,
providers don't automatically include the consumer which makes sense to
tbh. Maybe in some rare cases providers also need access to the consumer
API but that should be the exception and not the rule.

But we do have both flavors in the kernel (regulator provider does
include the consumer API).

IMHO, a full provider separation between provider and consumer both
living in include/linux or include/linux/dma would be what makes more
sense to me. Then a private header for the private stuff could indeed
live in drivers/dma/. But this would be a much bigger refactor.

Anyways, I'll reply to Vinod on how to move forward.

- Nuno Sá
> 
> 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
> > > >
> > > >