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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
