[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170827161032.22772-1-hch@lst.de>
Date: Sun, 27 Aug 2017 18:10:20 +0200
From: Christoph Hellwig <hch@....de>
To: iommu@...ts.linux-foundation.org
Cc: Marek Szyprowski <m.szyprowski@...sung.com>,
Robin Murphy <robin.murphy@....com>,
Michal Simek <monstr@...str.eu>,
David Howells <dhowells@...hat.com>,
Guan Xuetao <gxt@...c.pku.edu.cn>,
Chris Zankel <chris@...kel.net>,
Max Filippov <jcmvbkbc@...il.com>, x86@...nel.org,
linux-mips@...ux-mips.org, linux-ia64@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, linux-xtensa@...ux-xtensa.org,
linux-sh@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: refactor dma_cache_sync
The dma_cache_sync routines is used to flush caches for memory returned
by dma_alloc_attrs with the DMA_ATTR_NON_CONSISTENT flag (or previously
from dma_alloc_noncoherent), but the requirements for it seems to be
frequently misunderstood. dma_cache_sync is documented to be a no-op for
allocations that do not have the DMA_ATTR_NON_CONSISTENT flag set, and
yet a lot of architectures implement it in some way despite not
implementing DMA_ATTR_NON_CONSISTENT.
This series removes a few abuses of dma_cache_sync for non-DMA API
purposes, then changes all remaining architectures that do not implement
DMA_ATTR_NON_CONSISTENT to implement dma_cache_sync as a no-op, and
then adds the struct dma_map_ops indirection we use for all other
DMA mapping operations to dma_cache_sync as well, thus removing all but
two implementations of the function.
Powered by blists - more mailing lists