On Thu, Nov 03, 2016 at 01:03:56PM +0100, Ladislav Michl wrote: > On Thu, Nov 03, 2016 at 12:44:20PM +0100, Oliver Neukum wrote: > > On Thu, 2016-11-03 at 11:34 +0100, Ladislav Michl wrote: > > > Hi Oliver, > > > > > Device operates normally after reconnect. So it seems you were right, > > > there's no handling for EPIPE and EPROTO errors reported to acm_read_bulk_callback. > > > Following patch fixes it for me, if it looks okay for you, I'll resend it > > > properly. > > > > Hi, > > > > I am afraid we cannot just ignore or report -EPIPE. > > We need to clear a halt. Maybe your device would work > > if there were a delay in communication before the halt > > is cleared. I am not sure your patch is the right thing > > to do in all cases. > > > > Regards > > Oliver > > Hi Oliver, > > 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. 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. Also usb_clear_halt is called only from open in all drivers which do care about clearing a halt at all. Any pointers how should be such a error condition solved properly? (I didn't find any documentation and existing drivers do just the opposite) regards, ladis -- 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
