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 jgg@nvidia.com
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