On Wed, Jun 20, 2012 at 6:21 PM, Oliver Neukum <oneukum@xxxxxxx> wrote: > It probably was halted and cleared. However that you cleared > a halt doesn't mean that the reason for stalling went away. > So you must cope with an endpoint being halted again right after > it was cleared. I only suggested we should handle -EPIPE for usb_submit_urb on interrupt endpoint, maybe it is the 1st handling, at least it is per USB spec. Also from implementation of usb gadget device, generally ClearFeature(HALT) is to clear the some halt related flag of endpoint hardware. Looks the reasons of interrupt endpoint stalling is invisible for usbnet driver, so it is not easy to handle the situation you described(halted and cleared repeatedly). > >> > In that case we'd need to do something more intrusive >> > like resetting the device, but that cannot be done well >> > in the generic usbnet part. >> >> IMO, resetting is not needed for -EPIPE, but may be needed for >> -EPROTO failure. > > We don't need it for a single failure, but what else would we do > if we keep getting -EPIPE? Suppose the case will happen, what is the appropriate actions usbnet should take on the failure? I am not sure RESET can deal with it. Also is it a actual failure case or only a theory case? Thanks, -- Ming Lei -- 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
