[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181123130313.GI1586@8bytes.org>
Date: Fri, 23 Nov 2018 14:03:13 +0100
From: Joerg Roedel <joro@...tes.org>
To: Russell King - ARM Linux <linux@...linux.org.uk>
Cc: Robin Murphy <robin.murphy@....com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Christoph Hellwig <hch@....de>, linux-arch@...r.kernel.org,
linux-alpha@...r.kernel.org, linux-ia64@...r.kernel.org,
linux-parisc@...r.kernel.org,
David Woodhouse <dwmw2@...radead.org>,
the arch/x86 maintainers <x86@...nel.org>,
Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
iommu@...ts.linux-foundation.org, jdmason@...zu.us,
xen-devel@...ts.xenproject.org,
linux-arm-kernel@...ts.infradead.org, m.szyprowski@...sung.com
Subject: Re: remove the ->mapping_error method from dma_map_ops V2
On Fri, Nov 23, 2018 at 11:01:55AM +0000, Russell King - ARM Linux wrote:
> Yuck. So, if we have a 4GB non-PAE 32-bit system, or a PAE system
> where we have valid memory across the 4GB boundary and no IOMMU,
> we have to reserve the top 4K page in the first 4GB of RAM?
But that is only needed when dma_addr_t is 32bit anyway, no?
> Rather than inventing magic cookies like this, I'd much rather we
> sanitised the API so that we have functions that return success or
> an error code, rather than trying to shoe-horn some kind of magic
> error codes into dma_addr_t and subtly break systems in the process.
Sure, but is has the obvious downside that we need to touch every driver
that uses these functions, and that are probably a lot of drivers.
Regards,
Joerg
Powered by blists - more mailing lists