On 10/27/26 15:08, Jason Gunthorpe wrote: > 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?
I still don't see what you mean. If a driver can only deal with sgt then it won't implement the dma_buf_attach_ops->supported_mapping_types (or whatever we name that). So if either dma_buf_attach_ops is NULL or dma_buf_attach_ops->supported_mapping_types is NULL then we only match to the sgt export. What I want to avoid is to get just another dma_buf_attach() variant since we already added a parameter structure here. Regards, Christian. > > Jason
