Hi Christoph, On Fri, Jul 27, 2018 at 07:26:06PM +0200, Christoph Hellwig wrote: > mips_swiotlb_ops differs from the generic swiotlb_dma_ops only in that > it contains a mb() barrier after each operations that maps or syncs > dma memory to the device. > > The dma operations are defined to not be memory barriers, but instead > the write* operations to kick the DMA off are supposed to contain them. > > For mips this handled by war_io_reorder_wmb(), which evaluates to the > stronger wmb() instead of the pure compiler barrier barrier() for > just those platforms that use swiotlb, so I think we are covered > properly. > > Signed-off-by: Christoph Hellwig <h...@lst.de> > --- > arch/mips/include/asm/dma-mapping.h | 3 +- > arch/mips/mm/Makefile | 1 - > arch/mips/mm/dma-swiotlb.c | 61 ----------------------------- > 3 files changed, 1 insertion(+), 64 deletions(-) > delete mode 100644 arch/mips/mm/dma-swiotlb.c
Thanks - this looks reasonable, but needed a small tweak to gain the definition of swiotlb_dma_ops from linux/swiotlb.h (as riscv & unicore32 do) in order to avoid build failures. Hooray for even more deleted code :) Applied to mips-next for 4.19. Paul _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
