> From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb-owner@xxxxxxxxxxxxxxx] On Behalf Of Felipe Balbi > Sent: Wednesday, September 24, 2014 12:18 PM > > On Wed, Sep 24, 2014 at 01:08:15PM -0500, Felipe Balbi wrote: > > On Wed, Sep 24, 2014 at 01:53:31PM -0400, Alan Stern wrote: > > > On Wed, 24 Sep 2014, Felipe Balbi wrote: > > > > > > > > I'll capture usbmon and send here shortly. > > > > > > > > here it is... Interesting part starts at line 73 (114 on this email) > > > > where the data transport received EPIPE (due to Stall). This time > > > > however, I was eventually able to talk to the device and managed to > > > > issue quite a few writes to it. > > > > > > Here's where the unexpected stuff begins: > > > > > > > ed2541c0 1237463240 S Bo:003:01 -115 31 = 55534243 06000000 c0000000 8000061a 003f00c0 00000000 > 00000000 000000 > > > > ed2541c0 1237463431 C Bo:003:01 0 31 > > > > > ec1a8540 1237463873 S Bi:003:01 -115 192 < > > > > ec1a8540 1237464053 C Bi:003:01 -32 0 > > > > ed2541c0 1237464158 S Co:003:00 s 02 01 0000 0081 0000 0 > > > > ed2541c0 1237464359 C Co:003:00 0 0 > > > > ed2541c0 1237468607 S Bi:003:01 -115 13 < > > > > ed2541c0 1237468802 C Bi:003:01 -75 0 > > > > > > This is the first MODE SENSE command. The gadget should send as much > > > data as it can before halting the bulk-IN endpoint. Instead, the > > > endpoint was halted first. > > > > > > Then, after the host cleared the halt, the gadget apparently sent the > > > data that _should_ have been sent previously. The host was expecting > > > to receive the CSW at this point, so there was an overflow error. > > > That's what caused the host to perform a reset. > > > > > > Evidently this UDC implements the set_halt method incorrectly. > > > According to the kerneldoc for usb_ep_set_halt: > > > > > > * Attempts to halt IN endpoints will fail (returning -EAGAIN) if any > > > * transfer requests are still queued, or if the controller hardware > > > * (usually a FIFO) still holds bytes that the host hasn't collected. > > > > damn old bugs :-) I'll fix that up and Cc stable. > > alright fixed. Below you can see a combined diff which I'll still split > into patches so they can be applied properly. [ snipped patch which grubs around in the GDBGFIFOSPACE registers ] Ick. That shouldn't be necessary. The Synopsys vendor driver works fine with the mass-storage gadget (with stall=1) without doing anything like that. When did the dwc3 driver start showing this problem? Wouldn't it be better to find the change which caused this? Or has dwc3 always had this problem, but you never tested with stall=1 before so didn't see it? -- Paul -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
