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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 20 Feb 2019, Stanislaw Gruszka wrote:

> On Tue, Feb 19, 2019 at 10:40:47AM -0500, Alan Stern wrote:
> > On Tue, 19 Feb 2019, Stanislaw Gruszka wrote:
> > 
> > > It would be interesting why urb->num_sgs = 0 & urb->sg cause
> > > the troubles. This is how usb_sg_init() submit urbs for sg_tablesize = 0
> > > controllers. So either are there are some requirement on urb->sg
> > > mapped via dma_map_page() (which mt76usb does not meet) not needed
> > > for urb->transfer_buffer mapped via dma_map_single() or there
> > > is something wrong in dwc2 with sg and this driver will not
> > > work with urb_sg_init() as well. I don't have hardware to investigate
> > > this and don't want to bother you with more patches.
> > 
> > urb->sg != NULL and urb->num_sgs == 0 means that the transfer buffer 
> > must fit into a single page, which is pointed to by the first element 
> > of the scatterlist.
> 
> I asked about that in other thread 
> https://lore.kernel.org/linux-wireless/2cc5674a-a3a0-d8fe-65f5-4357da9b85d3@xxxxxxx/
> 
> the answer was it is weird but valid. However I think do dma_map_page()
> on buffer not fit in the single page is asking for troubles. I just posted
> patch that should fix this for mt76usb.
> 
> > But now that I look at the code in usb_sg_init(), it seems odd that the
> > !use_sg case doesn't increment sg during each loop iteration.  I don't
> > see how that could possibly work -- it looks like a bug!
> 
> Looks for me that this is done via for_each_sg(sg, sg, io->entries, i) loop.

Ah, of course.  Thanks for straightening me out; it's surprising what 
blind spots one's brain can develop.

Alan Stern




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux