On Tue, Oct 27, 2026 at 02:17:16PM +0100, Christian König wrote: > On 10/27/26 13:38, Jason Gunthorpe wrote: > > On Tue, Oct 27, 2026 at 01:07:36PM +0100, Christian König wrote: > >> On 10/26/26 06:36, Alistair Popple wrote: > >>> From: Jason Gunthorpe <[email protected]> > >>> > >>> This attach function always creates a SGT mapping type importer. > >> > >> Yeah that is a clear NO-GO. The attachment should be the same for > >> the new interface as well. > > > > Not sure I understand this comment... > > > > This was intended as a helper so that existing drivers can run through > > the sgt based mapping type flow without having to open code it. It is > > hardwired to only do sgt like this. If you want to use more than sgt > > as your mapping type don't use this function > > > > The point was to create a clear distinction in the API names when > > things were in a SGT-only flow vs using the newer negotiable flow. > > Well that is my point, the dma_buf_attach() or rather > dynamic_attach() function should still be part of the new flow.
It is, this is just a helper wrapper effectively to run the flow exactly as it is right now wired to only do sgt. Unless you want to see that open coded in ever driver using the more general functions, I'm not sure I see the alternative? Jason
