aboutsummaryrefslogtreecommitdiff
path: root/scripts/link-vmlinux.sh
diff options
context:
space:
mode:
authorRobin Murphy2017-08-31 11:32:54 +0100
committerChristoph Hellwig2017-09-01 09:49:17 +0200
commit723288836628bc1c0855f3bb7b64b1803e4b9e4a (patch)
treefcbae67d6c048e45caef3de2f4a9dca879d6b9fc /scripts/link-vmlinux.sh
parent2fd523c57e520899e05ec663d04743005bcef5b2 (diff)
of: restrict DMA configuration
Moving DMA configuration to happen later at driver probe time had the unnoticed side-effect that we now perform DMA configuration for *every* device represented in DT, rather than only those explicitly created by the of_platform and PCI code. As Christoph points out, this is not really the best thing to do. Whilst there may well be other DMA-capable buses that can benefit from having their children automatically configured after the bridge has probed, there are also plenty of others like USB, MDIO, etc. that definitely do not support DMA and should not be indiscriminately processed. The good news is that in most cases the DT "dma-ranges" property serves as an appropriate indicator - per a strict interpretation of the spec, anything lacking a "dma-ranges" property should be considered not to have a mapping of DMA address space from its children to its parent, thus anything for which of_dma_get_range() does not succeed does not need DMA configuration. Certain bus types have a general expectation of DMA capability and carry a well-established precedent that an absent "dma-ranges" implies the same as the empty property, so we automatically opt those in to DMA configuration regardless, to avoid regressing most existing platforms. Fixes: 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") Reported-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
Diffstat (limited to 'scripts/link-vmlinux.sh')
0 files changed, 0 insertions, 0 deletions