summaryrefslogtreecommitdiffstats
path: root/drivers/iommu/iommu.c
diff options
context:
space:
mode:
authorRobin Murphy <robin.murphy@arm.com>2017-02-01 17:53:04 +0000
committerJoerg Roedel <jroedel@suse.de>2017-02-06 13:14:10 +0100
commita1831bb9403720db6d4c033fe2d6bd0116dd28fe (patch)
tree2a2267ebdab46668c8e7063bdaef54336e67d6e5 /drivers/iommu/iommu.c
parent122fac030e912ed723fe94d8eb0d5d0f6b31535e (diff)
downloadtalos-obmc-linux-a1831bb9403720db6d4c033fe2d6bd0116dd28fe.tar.gz
talos-obmc-linux-a1831bb9403720db6d4c033fe2d6bd0116dd28fe.zip
iommu/dma: Remove bogus dma_supported() implementation
Back when this was first written, dma_supported() was somewhat of a murky mess, with subtly different interpretations being relied upon in various places. The "does device X support DMA to address range Y?" uses assuming Y to be physical addresses, which motivated the current iommu_dma_supported() implementation and are alluded to in the comment therein, have since been cleaned up, leaving only the far less ambiguous "can device X drive address bits Y" usage internal to DMA API mask setting. As such, there is no reason to keep a slightly misleading callback which does nothing but duplicate the current default behaviour; we already constrain IOVA allocations to the iommu_domain aperture where necessary, so let's leave DMA mask business to architecture-specific code where it belongs. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
Diffstat (limited to 'drivers/iommu/iommu.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud