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
signature.asc
Description: Digital signature
