Robin Murphy d89e2378a9 drivers: flag buses which demand DMA configuration ... We do not want the common dma_configure() pathway to apply indiscriminately to all devices, since there are plenty of buses which do not have DMA capability, and if their child devices were used for DMA API calls it would only be indicative of a driver bug. However, there are a number of buses for which DMA is implicitly expected even when not described by firmware - those we whitelist with an automatic opt-in to dma_configure(), assuming that the DMA address space and the physical address space are equivalent if not otherwise specified. Commit 7232888366 ("of: restrict DMA configuration") introduced a short-term fix by comparing explicit bus types, but this approach is far from pretty, doesn't scale well, and fails to cope at all with bus drivers which may be built as modules, like host1x. Let's refine things by making that opt-in a property of the bus type, which neatly addresses those problems and lets the decision of whether firmware description of DMA capability should be optional or mandatory stay internal to the bus drivers themselves. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Christoph Hellwig <hch@lst.de>		2017-10-19 16:34:52 +02:00
..
bus.c	drivers: flag buses which demand DMA configuration	2017-10-19 16:34:52 +02:00
Kconfig	amba: Hide TEGRA_AHB symbol	2015-11-24 16:47:25 +01:00
Makefile	ARM: tegra: Add Tegra AHB driver	2012-05-08 13:30:49 -06:00
tegra-ahb.c	ARM: 8334/1: amba: tegra-ahb: detect and correct bogus base address	2015-04-02 10:03:55 +01:00