On Thu, Aug 20, 2015 at 04:12:24PM -0400, Alan Stern wrote: > On Thu, 20 Aug 2015, Felipe Balbi wrote: > > > Hi, > > > > On Thu, Aug 20, 2015 at 01:08:30PM -0400, Alan Stern wrote: > > > On Thu, 20 Aug 2015, Felipe Balbi wrote: > > > > > > > > > > - Test 13 will fail due to there is pending IN request > > > > > > > (f_sourcesink > > > > > > > will queue a request unconditionally at its completion), and udc > > > > > > > driver > > > > > > > will run out error if that. udc driver must do that if it wants to > > > > > > > > > > > > wait, what ? test 13 works just fine here. (I'll try again in a few > > > > > > minutes just to make sure) > > > > > > > > > > It may depend on what UDC and what test device you use. > > > > > > > > Why ? Why would SET_FEATURE(HALT) fail ? I can only see it as a bug on > > > > the UDC driver. A bug which should be fixed. > > > > > > Here's what the kerneldoc for usb_ep_set_halt() says: > > > > > > * Returns zero, or a negative error code. On success, this call sets > > > * underlying hardware state that blocks data transfers. > > > * 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. > > > > > > That's talking about IN endpoints only, not OUT -- but Peter's original > > > email mentioned that Test 13 fails if there's a pending IN usb_request. > > > > oh right, IN endpoints are special in that sense :-) > > > > But that's only true for some cases. When host side sends > > SetFeature(HALT), that should always succeed, right ? > > > > See commit 7a60855972f0d for example. > > Yeah, that fixed DWC3. Peter didn't say which UDC driver he was using. > > I went back and looked at net2280. That driver treates Set-Halt > requests from the host differently from set_halt() calls from the > gadget driver. The request from the host always succeeds immediately, > whereas the call from the gadget driver fails if the request queue or > the hardware FIFO is non-empty. > > So it looks like Test 13 should work with net2280. And indeed it > does; I just tried it. > > > Doesn't Peter need to cope with differentiating protocol vs non-protocol > > stalls ? > > Those matter only for ep0, not for bulk/interrupt.
huh ? usbtest send SetFeature(HALT) for the bulk endpoint, right ? That's what Peter's UDC driver is missing. It's this special case of halting the endpoint when the host asks it to regardless of having queued struct usb_requests or not. -- balbi
signature.asc
Description: Digital signature
