Re: Some restrictions when using usbtest and g_zero

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

 



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

Attachment: signature.asc
Description: Digital signature


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

  Powered by Linux