On 2019-02-19 11:42, Stanislaw Gruszka wrote: > On Mon, Feb 18, 2019 at 07:52:27PM +0100, Felix Fietkau wrote: >> On 2019-02-18 16:03, Stanislaw Gruszka wrote: >> > On Mon, Feb 18, 2019 at 03:43:26PM +0100, Felix Fietkau wrote: >> >> On 2019-02-18 14:52, Stanislaw Gruszka wrote: >> >> > On Sat, Feb 16, 2019 at 08:17:07PM +0100, Stefan Wahren wrote: >> >> >> 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. >> > >> > I decided to this patch because I thought some other USB & MMIO DMA >> > platforms might also require this alignment. But it was never triggered >> > in MMIO because on those mt76 is used in AP mode, hence no PROBE >> > REQUEST frames (and scan can be passive on STA mode). >> mt76 is regularly used and tested in STA and Mesh mode as well. >> No DMA alignment related issues there. > > The question is why we need to do 2 bytes header pad ? Is this because > ieee802.11 header length for mt76 hardware has to be multiple of 4 or > it has to be aligned to 4 bytes? It would be strange if length has > to be fixed to 4 bytes and alignment not. However this could be > needed on some platforms and not on others. Not sure why it was added in the hardware, but the MAC assumes that the header is padded to a multiple of 4 bytes in the buffer after it has been copied to device memory via DMA or USB. Because of that, it has nothing to do with the alignment of the source buffer, so the two should not be mixed up. >> >> 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 >> > >> > I agree, if this is only needed for dwc2. Though I would investigate >> > if this is not a bug on other platforms as well. >> >From what I can see, using Lorenzo's patches seems to be the better >> solution, since they avoid these corner cases in dwc2 (and maybe other >> drivers as well). I will apply them and then we'll see if we need to do >> any further improvements later on. > > They work on rpi dwc2, but they do not address root of the problem. > There is clearly something wrong how mt76usb handle SG, what is not > fixed. And adding disable_usb_sg module parameter for hcd's supporting > SG should be red flag. I think we're simply dealing with multiple issues here, only some of which are fixed by Lorenzo's patches. I'm pretty sure it's still wrong for mt76 to try to align its buffers, since the Linux USB API supports non-aligned transfer buffers and it should be up to the controller driver to deal with that. dwc2 tries to do that, but that has limitations which I already pointed out and which are properly dealt with by Lorenzo's patches. Any other issues with sg should be investigated separately, they are probably unrelated to this one. - Felix
