linux/drivers/of/device.c

343 lines
8.1 KiB

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>
2017-08-31 11:32:54 +01:00
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>
2017-08-31 11:32:54 +01:00
of: fix DMA mask generation Historically, DMA masks have suffered some ambiguity between whether they represent the range of physical memory a device can access, or the address bits a device is capable of driving, particularly since on many platforms the two are equivalent. Whilst there are some stragglers left (dma_max_pfn(), I'm looking at you...), the majority of DMA code has been cleaned up to follow the latter definition, not least since it is the only one which makes sense once IOMMUs are involved. In this respect, of_dma_configure() has always done the wrong thing in how it generates initial masks based on "dma-ranges". Although rounding down did not affect the TI Keystone platform where dma_addr + size is already a power of two, in any other case it results in a mask which is at best unnecessarily constrained and at worst unusable. BCM2837 illustrates the problem nicely, where we have a DMA base of 3GB and a size of 1GB - 16MB, giving dma_addr + size = 0xff000000 and a resultant mask of 0x7fffffff, which is then insufficient to even cover the necessary offset, effectively making all DMA addresses out-of-range. This has been hidden until now (mostly because we don't yet prevent drivers from simply overwriting this initial mask later upon probe), but due to recent changes elsewhere now shows up as USB being broken on Raspberry Pi 3. Make it right by rounding up instead of down, such that the mask correctly correctly describes all possisble bits the device needs to emit. Fixes: 9a6d7298b083 ("of: Calculate device DMA masks based on DT dma-range size") Reported-by: Stefan Wahren <stefan.wahren@i2se.com> Reported-by: Andreas Färber <afaerber@suse.de> Reported-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-08-11 17:29:56 +01:00
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>
2017-08-31 11:32:54 +01:00
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>
2017-08-31 11:32:54 +01:00
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>
2017-08-31 11:32:54 +01:00
of: fix DMA mask generation Historically, DMA masks have suffered some ambiguity between whether they represent the range of physical memory a device can access, or the address bits a device is capable of driving, particularly since on many platforms the two are equivalent. Whilst there are some stragglers left (dma_max_pfn(), I'm looking at you...), the majority of DMA code has been cleaned up to follow the latter definition, not least since it is the only one which makes sense once IOMMUs are involved. In this respect, of_dma_configure() has always done the wrong thing in how it generates initial masks based on "dma-ranges". Although rounding down did not affect the TI Keystone platform where dma_addr + size is already a power of two, in any other case it results in a mask which is at best unnecessarily constrained and at worst unusable. BCM2837 illustrates the problem nicely, where we have a DMA base of 3GB and a size of 1GB - 16MB, giving dma_addr + size = 0xff000000 and a resultant mask of 0x7fffffff, which is then insufficient to even cover the necessary offset, effectively making all DMA addresses out-of-range. This has been hidden until now (mostly because we don't yet prevent drivers from simply overwriting this initial mask later upon probe), but due to recent changes elsewhere now shows up as USB being broken on Raspberry Pi 3. Make it right by rounding up instead of down, such that the mask correctly correctly describes all possisble bits the device needs to emit. Fixes: 9a6d7298b083 ("of: Calculate device DMA masks based on DT dma-range size") Reported-by: Stefan Wahren <stefan.wahren@i2se.com> Reported-by: Andreas Färber <afaerber@suse.de> Reported-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-08-11 17:29:56 +01:00