Commit 7bd6680b authored by Will Deacon's avatar Will Deacon
Browse files

Revert "Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()"" 



This reverts commit b7d9aae4.

With the Qualcomm remoteproc driver now modified to use a carveout
memory region in 57f72170 ("remoteproc: qcom_q6v5_mss: Use a
carveout to authenticate modem headers"), we can reinstate c44094ee
("arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()")
which relaxes the arm64 implementation of arch_dma_prep_coherent() to
perform only a data cache clean operation, rather than a
clean-and-invalidate.

Signed-off-by: default avatarWill Deacon <will@kernel.org>
parent 7cae569e

arch/arm64/mm/dma-mapping.c

+1 −16
Original line number Diff line number Diff line
@@ -36,22 +36,7 @@ void arch_dma_prep_coherent(struct page *page, size_t size) 
{

	unsigned long start = (unsigned long)page_address(page);



	/*

	 * The architecture only requires a clean to the PoC here in order to

	 * meet the requirements of the DMA API. However, some vendors (i.e.

	 * Qualcomm) abuse the DMA API for transferring buffers from the

	 * non-secure to the secure world, resetting the system if a non-secure

	 * access shows up after the buffer has been transferred:

	 *

	 * https://lore.kernel.org/r/20221114110329.68413-1-manivannan.sadhasivam@linaro.org

	 *

	 * Using clean+invalidate appears to make this issue less likely, but

	 * the drivers themselves still need fixing as the CPU could issue a

	 * speculative read from the buffer via the linear mapping irrespective

	 * of the cache maintenance we use. Once the drivers are fixed, we can

	 * relax this to a clean operation.

	 */

	dcache_clean_inval_poc(start, start + size);

	dcache_clean_poc(start, start + size);

}



#ifdef CONFIG_IOMMU_DMA