remove the ->mapping_error method from dma_map_ops V2
From: torvalds@linux-foundation.org (Linus Torvalds)
Date: 2018-11-28 16:47:40
Also in:
linux-alpha, linux-arch, linux-iommu, lkml
From: torvalds@linux-foundation.org (Linus Torvalds)
Date: 2018-11-28 16:47:40
Also in:
linux-alpha, linux-arch, linux-iommu, lkml
On Tue, Nov 27, 2018 at 11:41 PM Christoph Hellwig [off-list ref] wrote:
On Fri, Nov 23, 2018 at 07:55:11AM +0100, Christoph Hellwig wrote:quoted
Well, I can tweak the last patch to return -EINVAL from dma_mapping_error instead of the old 1 is as bool true. The callers should all be fine, although I'd have to audit them. Still wouldn't help with being able to return different errors.Any opinions? I'd really like to make some forward progress on this series.
So I do think that yes, dma_mapping_error() should return an error
code, not 0/1.
But I was really hoping that the individual drivers themselves could
return error codes. Right now the patch-series has code like this:
ret = needs_bounce(dev, dma_addr, size);
if (ret < 0)
- return ARM_MAPPING_ERROR;
+ return DMA_MAPPING_ERROR;
which while it all makes sense in the context of this patch-series, I
*really* think it would have been so much nicer to return the error
code 'ret' instead (which in this case is -E2BIG).
I don't think this is a huge deal, but ERR_PTR() has been hugely
successful elsewhere. And I'm not hugely convinced about all these
"any address can be valid" arguments. How the hell do you generate a
random dma address in the last page that isn't even page-aligned?
Linus