Re: Some restrictions when using usbtest and g_zero

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

 



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.

Alan Stern

--
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



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

  Powered by Linux