Hello, We've been facing a bug with the new CESA driver on armada 370 for a couple of days. Arnaud found out that this bug appeared when we fixed the req->src == req->dst case (by passing DMA_BIDIRECTIONAL when mapping the sg list instead of mapping the same sg list twice, once with the TO_DEVICE option and the second time with the FROM_DEVICE option). After further investigations, we found out that invalidating the cache (in addition to the clean operation already done when mapping the region for DMA with the BIDIR option) was somehow fixing the problem. Which led us to think that this could be related to a non cache-line aligned buffer problem: if we share the cache line with someone modifying its data during the DMA transfer, we could experience data loss when the cpu decide to flush the data from this cache line to the memory. Russel, Will, could you confirm this is an issue that could happen ? To validate this assumption we decided to test the alignment of the src and dst sg list entries passed by the crypto framework, and most of them are indeed not aligned on ARCH_DMA_MINALIGN. We made a dirty hack to copy the content of non aligned sg lists into a new ones containing a single aligned buffer (allocated with kmalloc) and it seems to solve the problem. We also noticed that the cra_alignmask fields were all set to 0 in the CESA driver, but modifying them (setting them to ARCH_DMA_MINALIGN - 1) does not seem to guarantee any alignment. ITOH, the xxx_walk_xxx API seem to check these misalignment issues and allocate new buffers to prevent such cases, but AFAICT, this is not automatically done by the crypto framework, and it's the responsibility of each driver to ensure the correct alignment. Herbert, could you confirm that ? Do you see anything else we should check ? Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- 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
