On Tue, Apr 27, 2021 at 08:01:13PM -0300, Jason Gunthorpe wrote: > At a high level I'm OK with it. dma_map_sg_attrs() is the extra > extended version of dma_map_sg(), it already has a different > signature, a different return code is not out of the question. > > dma_map_sg() is just the simple easy to use interface that can't do > advanced stuff. > > > I'm not that opposed to this. But it will make this series a fair bit > > longer to change the 8 map_sg_attrs() usages. > > Yes, but the result seems much nicer to not grow the DMA API further. We already have a mapping function that can return errors: dma_map_sgtable. I think it might make more sense to piggy back on that, as the sg_table abstraction is pretty useful basically everywhere that we deal with scatterlists anyway. In the hopefully no too long run I plan to get rid of scatterlists in at least NVMe and other high performance devices anyway.
