On Thu, 11 Jun 2009, Russell King - ARM Linux wrote: > For these interfaces, I am a strong believer in purpose-defined > interfaces to caches and the like. If what we have doesn't provide > what's required, we need to provide something else. > > So, the question is what are you trying to do with this > dmac_flush_range() and your SRAM? Are you trying to achieve I/D cache > coherency for data written there, so you can execute it later, or are > you trying to ensure DMA coherency from SRAM? It is a typical case of cache coherency between kernel and user space. The Orion crypto engine works on data stored in a block of SRAM. Currently the driver does not (yet) make use of the available DMA to copy data back and forth between SRAM and main memory. At the moment it uses memcpy() which dirties the cache when the data is copied back to the kernel memory. Amongst users of the crypto API you have dm_crypt which makes decrypted data visible to user space. So we get the same classic corruption effect on ARM as with a hardware block driver using PIO without flush_dcache_page(). Other kernel based crypto users don't have that issue of course. It is of course the goal to use DMA instead of memcpy() eventually, at which point there won't be any dirty data in the cache and this issue will go away. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
