[PATCH 1/3] crypto: marvell/cesa - replace dma_to_phys with dma_map_single
From: Boris Brezillon <hidden>
Date: 2016-03-18 11:32:22
Also in:
linux-crypto, lkml
On Fri, 18 Mar 2016 11:25:48 +0000 Robin Murphy [off-list ref] wrote:
On 18/03/16 09:30, Boris Brezillon wrote:quoted
On Thu, 17 Mar 2016 23:50:20 +0000 Russell King - ARM Linux [off-list ref] wrote:quoted
On Thu, Mar 17, 2016 at 07:17:24PM -0400, okaya at codeaurora.org wrote:quoted
What is the correct way? I don't want to write engine->sram_dma = sramWell, what the driver _is_ wanting to do is to go from a CPU physical address to a device DMA address. phys_to_dma() looks like the correct thing there to me, but I guess that's just an offset and doesn't take account of any IOMMU that may be in the way. If you have an IOMMU, then the whole phys_to_dma() thing is a total failure as it only does a linear translation, and there are no interfaces in the kernel to take account of an IOMMU in the way. So, it needs something designed for the job, implemented and discussed by the normal methods of proposing a new cross-arch interface for drivers to use. What I'm certain of, though, is that the change proposed in this patch will break current users of this driver: virt_to_page() on an address returned by ioremap() is completely undefined, and will result in either a kernel oops, or if not poking at memory which isn't a struct page, ultimately resulting in something that isn't SRAM being pointed to by "engine->sram_dma".Or we could just do engine->sram_dma = res->start; which is pretty much what the SRAM/genalloc code is doing already.As Russell points out this is yet another type of "set up a DMA master to access something other than kernel RAM" - there's already discussion in progress over how to handle this for dmaengine slaves[1], so gathering more use-cases might help distil exactly what the design of not-strictly-DMA-but-so-closely-coupled-it-can't-really-live-anywhere-else needs to be. Robin. [1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/414422.html
Hm, interesting, thanks for the pointer. -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com