Bug in split transactions on Raspberry Pi

[Alan Stern]

On Tue, 26 Jan 2016, Doug Anderson wrote:

> > This probably indicates that the list of patches was incomplete (i.e.,
> > some other patches were applied before these).  Also, the patches
> > aren't listed in order of the patchwork IDs -- which order is correct?
> 
> The order like 01, 02, 03, etc is correct.  Patchwork numbers things
> in a random order (depending on the vagaries of SMTP and which one
> arrives to their server first).
> 
> Ah, I had tried linux/master recently, but that has a patch that's not in v4.4:
> 
> fbb9e22b15ad usb: dwc2: host: enable descriptor dma for fs devices
> 
> 
> I'd bet that you don't have descriptor DMA turned on anyway, so the
> descriptor DMA patches won't really matter (they'll just be noops).
> ...but you could pick all the patches up to that one to avoid
> conflicts.
> 
> fbb9e22b15ad usb: dwc2: host: enable descriptor dma for fs devices
> 762d3a1a9cd7 usb: dwc2: host: process all completed urbs
> 3f808bdae75e usb: dwc2: host: always increment available host channel
> during release
> c17b337c1ea4 usb: dwc2: host: program descriptor for next frame
> b9392d9920fd usb: dwc2: host: add function to compare frame index
> 2b046bc5aaef usb: dwc2: host: spinlock release channel
> 26a19ea69906 usb: dwc2: host: fix use of qtd after free in desc dma mode
> c503b3815385 usb: dwc2: host: rework isochronous halt path
> dde4c1bf5df0 usb: dwc2: host: set active bit in isochronous descriptors
> 3ac38d260fa5 usb: dwc2: host: ensure filling of isoc desc is correctly done

In the end I just used the contents of the dwc2 directory from Linus's 
current tree -- I don't think it has changed since 4.5-rc1.  Your 
patches applied on top of that with no issues.

They seem to work.  Is there anything in particular you would like me 
to test?

One problem I noticed: The controller does hub status polling to an
external high-speed hub much too frequently.  The interrupt endpoint's
bInterval value is 12, meaning the polling interval should be 256 ms.  
But when data was available, the polls were issued every 2 microframes
instead of every 2048.

Could the driver be rescheduling the interrupt endpoint every time an
URB completes and a new one is submitted?  That's what it looks like.  
This might be related to the giving-URBs-back-in-a-tasklet change.

Alan Stern