| Message ID | a85a5fe22fced65b2960251fc6e8d8f1e68f828a.1531239284.git.robin.murphy@arm.com (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
On 10/07/18 19:04, Christoph Hellwig wrote: > On Tue, Jul 10, 2018 at 06:17:16PM +0100, Robin Murphy wrote: >> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c >> index 8be8106270c2..95e185347e34 100644 >> --- a/kernel/dma/direct.c >> +++ b/kernel/dma/direct.c >> @@ -183,7 +183,7 @@ int dma_direct_supported(struct device *dev, u64 mask) >> * Various PCI/PCIe bridges have broken support for > 32bit DMA even >> * if the device itself might support it. >> */ >> - if (dev->dma_32bit_limit && mask > DMA_BIT_MASK(32)) >> + if (dev->bus_dma_mask && mask > dev->bus_dma_mask) >> return 0; > > The comment above this check needs an updated (or just be removed). Right, I'll give it a tweak. I could also do with actually getting the field name correct in via_no_dac_cb()... > Also we still have a few architectures not using dma-direct. I guess > most were doing fine without such limits anyway, but at least arm > will probably need an equivalent check. Indeed, once we've found an approach that everyone's happy with we can have a more thorough audit of exactly where else it needs to be applied. FWIW I'm not aware of any 32-bit Arm systems affected by this*, but if they do exist then at least there's no risk of regression since they've always been busted. Robin. * Not counting the somewhat-similar StrongArm DMA controller bug where one bit in the *middle* of the mask is unusable. Let's keep that confined to the Arm dmabounce code and never speak of it... -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jul 11, 2018 at 05:56:40PM +0100, Robin Murphy wrote: > Indeed, once we've found an approach that everyone's happy with we can have > a more thorough audit of exactly where else it needs to be applied. FWIW > I'm not aware of any 32-bit Arm systems affected by this*, but if they do > exist then at least there's no risk of regression since they've always been > busted. Ok, great. I just assumed arm might be affected due to the fact that it currently parses dma-ranges DT properties. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c index ab5d9dd668d2..0b60f2a9dace 100644 --- a/arch/x86/kernel/pci-dma.c +++ b/arch/x86/kernel/pci-dma.c @@ -175,7 +175,7 @@ rootfs_initcall(pci_iommu_init); static int via_no_dac_cb(struct pci_dev *pdev, void *data) { - pdev->dev.dma_32bit_limit = true; + pdev->dev_dma_mask = DMA_BIT_MASK(32); return 0; } diff --git a/include/linux/device.h b/include/linux/device.h index 055a69dbcd18..6d3b000be57e 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -886,6 +886,8 @@ struct dev_links_info { * @coherent_dma_mask: Like dma_mask, but for alloc_coherent mapping as not all * hardware supports 64-bit addresses for consistent allocations * such descriptors. + * @bus_dma_mask: Mask of an upstream bridge or bus which imposes a smaller DMA + * limit than the device itself supports. * @dma_pfn_offset: offset of DMA memory range relatively of RAM * @dma_parms: A low level driver may set these to teach IOMMU code about * segment limitations. @@ -912,8 +914,6 @@ struct dev_links_info { * @offline: Set after successful invocation of bus type's .offline(). * @of_node_reused: Set if the device-tree node is shared with an ancestor * device. - * @dma_32bit_limit: bridge limited to 32bit DMA even if the device itself - * indicates support for a higher limit in the dma_mask field. * * At the lowest level, every device in a Linux system is represented by an * instance of struct device. The device structure contains the information @@ -967,6 +967,7 @@ struct device { not all hardware supports 64 bit addresses for consistent allocations such descriptors. */ + u64 bus_dma_mask; /* upstream dma_mask constraint */ unsigned long dma_pfn_offset; struct device_dma_parameters *dma_parms; @@ -1002,7 +1003,6 @@ struct device { bool offline_disabled:1; bool offline:1; bool of_node_reused:1; - bool dma_32bit_limit:1; }; static inline struct device *kobj_to_dev(struct kobject *kobj) diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index 8be8106270c2..95e185347e34 100644 --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -183,7 +183,7 @@ int dma_direct_supported(struct device *dev, u64 mask) * Various PCI/PCIe bridges have broken support for > 32bit DMA even * if the device itself might support it. */ - if (dev->dma_32bit_limit && mask > DMA_BIT_MASK(32)) + if (dev->bus_dma_mask && mask > dev->bus_dma_mask) return 0; return 1; }
Whilst the notion of an upstream DMA restriction is most commonly seen via PCI host bridges saddled with a 32-bit native interface, a more general version of the same issue can exist on complex SoCs where a bus or point-to-point interconnect link carries fewer address bits between a device and a downstream component (often an IOMMU) than both blocks nominally support. In order to properly deal with this, first grow the dma_32bit_limit flag into an arbitrary mask. To minimise the impact on existing code, we'll only consider this new mask valid if set. That makes sense anyway, since cases where DMA is not wired up at all would be better handled by not giving the device valid ops in the first place. Signed-off-by: Robin Murphy <robin.murphy@arm.com> --- arch/x86/kernel/pci-dma.c | 2 +- include/linux/device.h | 6 +++--- kernel/dma/direct.c | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-)