On Fri, 21 Aug 2015, Peter Chen wrote: > Thanks, Alan and Felipe. > > My problem should be the chipidea udc driver does not support functional > stall well, it fixes the handling between functional and protocol stall. > > My understanding for these two stalls: > > - Functional stall, the host stalls the endpoints through SET_FEATURE > by ep0, the ep0 does not recommend to support functional stall from > the spec. The device should always set stall for this endpoint, and > return success for it. That's almost right. I just checked the USB spec to make sure (section 8.4.5). A functional stall occurs whenever the endpoint's HALT feature is set. This could be caused the host sending a Set-Halt request, _or_ it could be caused by the device's firmware (for example, by a call to usb_ep_set_halt()). Either way, the endpoint continues to stall until the host sends a Clear-Halt request. (And yes, the spec recommends that devices should not set the HALT feature for ep0. If they do, it is undefined whether the device will respond to a Clear-Halt request!) > - Protocol stall, if the endpoint doesn't support one request, it can > stall itself. If there is an IN request on this endpoint, it should > not do stall, and return error. Protocol stalls occur only on control endpoints; they indicate the device does not understand or cannot carry out a control request. They are automatically cleared the next time a Setup packet arrives. So if you're talking about a bulk/interrupt endpoint, the only kind of stall you have to worry about is a functional stall. The host can cause a functional stall at any time by sending Set-Halt. The gadget driver can also cause a functional stall, but it makes no sense to do so while it is in the middle of transferring data to/from the host. For this reason, usb_ep_set_halt() always returns an error if the endpoint queue or the FIFO is non-empty. 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
