On Thu, 2016-11-03 at 13:44 +0100, Ladislav Michl wrote: > On Thu, Nov 03, 2016 at 01:03:56PM +0100, Ladislav Michl wrote: Hi, > > now I'm really confused. Just looked at drivers/usb/serial/generic.c > > which just stops submitting urbs on -EPIPE. On contrary > > drivers/usb/serial/ti_usb_3410_5052.c does just the opposite. > > I'm assuming generic function does it right, but what do you > > mean by "clearing a halt"? > > This really feels like opening Pandora's box... So usb generic is submitting > read urbs on all error except -EPIPE (and -ENOENT, -ECONNRESET, -ESHUTDOWN > of course). cypress_m8 stops submitting on all errors and adds comment > "Can't call usb_clear_halt while in_interrupt" to -EPIPE case. True. That driver is so old that the error was hard to handle. > Edgeport and TI 3410/5052 drivers has special case for -EPIPE where they > continue submitting read urbs. There's pretty clear pattern showing which > driver is derived from other, but all of them simply cannot be right. They are for different hardware. > Also usb_clear_halt is called only from open in all drivers which do care > about clearing a halt at all. No. For example look at usbnet. > Any pointers how should be such a error condition solved properly? > (I didn't find any documentation and existing drivers do just the opposite) I think the way usbnet handles -EPIPE is the best. We are a bit on thin ice because the CDC spec does not list under which conditions we should see a stall, thus by implication: never. But in general you cannot ignore a stall. You need to clear the halt. We cannot do full error handling for modems because they would drop the connection if we reset the device. Regards Oliver -- 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
