On 10/07/18 19:04, Christoph Hellwig wrote:

On Tue, Jul 10, 2018 at 06:17:16PM +0100, Robin Murphy wrote:

quoted

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...