Commit 8ed710da authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux 

Pull arm64 fix from Catalin Marinas:
 "Revert the dropping of the cache invalidation from the arm64
  arch_dma_prep_coherent() as it caused a regression in the
  qcom_q6v5_mss remoteproc driver.

  The driver is already buggy but the original arm64 change made
  the problem obvious. The change will be re-introduced once the
  driver is fixed"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()"
parents 5b3e0cd8 b7d9aae4

arch/arm64/mm/dma-mapping.c

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

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



	dcache_clean_poc(start, start + size);

	/*

	 * 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);

}



#ifdef CONFIG_IOMMU_DMA