Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+

From: Felix Fietkau <nbd@nbd.name>
Date: 2019-02-18 14:43:26
Also in: linux-usb

On 2019-02-18 14:52, Stanislaw Gruszka wrote:
On Sat, Feb 16, 2019 at 08:17:07PM +0100, Stefan Wahren wrote:
quoted
this is a misunderstanding. The warning is about memory alignment to 32 bit addresses, not about page alignment. This is a typical ARM restriction. Maybe we need to make sure in mt76 that the DMA buffer needs to be aligned. But it's also possible that the warning isn't the root cause of our problem.
I see, it needs 4 bytes alignment . There is already dwc2 code checks
that and allocate new buffer if the alignment is not right:
dwc2_alloc_dma_aligned_buffer(), but it does nothing if urb->sg
is not NULL. I thought mt76usb already provide aligned buffers, but
looks it does not for one TX special case, which are PROBE REQUEST
frames. Other frames are aligned by inserting L2 header pad. One
solution for this would be just submit urb with  NULL sg (same as
Lorenzo's patches do, but still allocating buffers via buf->sg),
but I think, you have right, we should provide 4 bytes aligned buffers
by default as other DMA hardware may require that. I'm attaching yet
another patch to test, which fix up alignment for PROBE REQUEST frames.
This approach looks completely wrong to me. MMIO based hardware does not
need 4-byte aligned buffers at all, other USB controllers do not need
this either.
As Lorenzo already pointed out, re-aligning the buffer is *very*
expensive, so we should not do this in the driver just to work around
quirks in a particular USB host driver.
And I really don't think we can assume that this code path is going to
be hit for probe requests only.

The way I see it, we have two choices.
1. Fix dwc2 to do its alignment quirk for the urb->sg != NULL case
2. Rely on urb->transfer_buffer and keep urb->sg NULL

- Felix
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help