On Thu, Aug 20, 2015 at 10:40:17AM -0400, Alan Stern wrote:
> On Thu, 20 Aug 2015, Peter Chen wrote:
>
> > Hi all,
> >
> > I have played usbtest and g_zero (f_sourcesink & f_loopback) to do
> > the tests between two boards these days, and have found some restrictions,
> > I list them here, and to see if they are common problems and can
> > be improved or not.
> >
> > - 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
> > pass USB CV2.0 MSC TEST. (othwerwise, "Command Set Test - Device Configured"
> > will fail)
>
> The USB spec isn't very clear about this. All it says about the
> Set-Halt request is:
>
> When set by the SetFeature() request, the endpoint exhibits the
> same stall behavior as if the field had been set by a hardware
> condition.
>
> But if there's a pending request, many UDC drivers are unable to set
> the HALT feature -- even due to a hardware condition.
>
> I suppose the right thing is for the UDC to temporarily disable the
> endpoint, set the HALT feature, and then re-enable the endpoint (along
> with the pending request). But changing a bunch of UDC drivers for
> such a minor thing doesn't seem worthwhile.
we can move that into udc-core.c:
int usb_ep_set_halt(struct usb_ep *ep)
{
if (WARN_ON(!ep))
return -EINVAL;
if (!usb_ep_queue_is_empty(ep))
usb_ep_empty_queue(ep, -EPIPE);
return __usb_ep_set_halt(ep);
}
or something similar.
--
balbi
Attachment:
signature.asc
Description: Digital signature
