On 6/5/19 5:50 PM, Aaro Koskinen wrote:
> Hi,
>
> When upgrading from v5.0 -> v5.1 on G4 PowerBook, I noticed WLAN does
> not work anymore:
>
> [ 42.004303] b43legacy-phy0: Loading firmware version 0x127, patch level 14 (2005-04-18 02:36:27)
> [ 42.184837] b43legacy-phy0 debug: Chip initialized
> [ 42.184873] b43legacy-phy0 ERROR: The machine/kernel does not support the required 30-bit DMA mask
>
> The same happens with the current mainline.
>
> Bisected to:
>
> commit 65a21b71f948406201e4f62e41f06513350ca390
> Author: Christoph Hellwig <[email protected]>
> Date: Wed Feb 13 08:01:26 2019 +0100
>
> powerpc/dma: remove dma_nommu_dma_supported
>
> This function is largely identical to the generic version used
> everywhere else. Replace it with the generic version.
>
> Signed-off-by: Christoph Hellwig <[email protected]>
> Tested-by: Christian Zigotzky <[email protected]>
> Signed-off-by: Michael Ellerman <[email protected]>
Aaro,
Please try the attached patch. I'm not really pleased with it and I will
continue to determine why the fallback to a 30-bit mask fails, but at least this
one works for me.
Larry
I don't think we should work around this in the driver, we need to fix
it in the core. I'm curious why my previous patch didn't work. Can
you throw in a few printks what failed? I.e. did dma_direct_supported
return false? Did the actual allocation fail?
On 6/7/19 12:29 PM, Christoph Hellwig wrote:
> I don't think we should work around this in the driver, we need to fix
> it in the core. I'm curious why my previous patch didn't work. Can
> you throw in a few printks what failed? I.e. did dma_direct_supported
> return false? Did the actual allocation fail?
I agree that that patch should not be sent upstream. I posted it only so that
anyone running into the problem would have a work around.
I will try to see why your patch failed.
Larry
> Please try the attached patch. I'm not really pleased with it and I will
> continue to determine why the fallback to a 30-bit mask fails, but at least this
> one works for me.
Your patch only makes sense if the device is indeed capable of
addressing 31-bits.
So either the driver is buggy and asks for a too small mask in which
case your patch is ok, or it's not and you're just going to cause all
sort of interesting random problems including possible memory
corruption.
Cheers,
Ben.
On 6/7/19 12:29 PM, Christoph Hellwig wrote:
> I don't think we should work around this in the driver, we need to fix
> it in the core. I'm curious why my previous patch didn't work. Can
> you throw in a few printks what failed? I.e. did dma_direct_supported
> return false? Did the actual allocation fail?
Routine dma_direct_supported() returns true.
The failure is in routine dma_set_mask() in the following if test:
if (!dev->dma_mask || !dma_supported(dev, mask))
return -EIO;
For b43legacy, dev->dma_mask is 0xc265684800000000.
dma_supported(dev, mask) is 0xc08b000000000000, mask is 0x3fffffff, and the
routine returns -EIO.
For b43, dev->dma_mask is 0xc265684800000001,
dma_supported(dev, mask) is 0xc08b000000000000, mask is 0x77777777, and the
routine returns 0.
Thus far I have not found what sets the low-order bit of dev->dma_mask.
Suggestions are welcome.
These tests have all been with your patch that sets ARCH_ZONE_DMA_BITS to 30.
Larry