linux-usb, Apologies if I've come at this the wrong way, I've read MAINTAINERS and usb-serial.txt to get your name. Kernel 3.15 added logic to usb_serial_generic_read_bulk_callback() to resubmit read URBs in the general/default fail case (for failures other than urb->status = ENOENT, ECONNRESET, ESHUTDOWN. Also EPIPE). On Raspberry Pi, running a 3.18 kernel, I am seeing -EPROTO as the urb->status in usb_serial_generic_read_bulk_callback() when the last CP210X USB-UART device is removed from a hub (the hub remains attached to the Raspberry Pi). ((removing a non-last CP210X from the hub, does not return EPROTO, does return one of the specifically identified errnos)). The URB is retried, which fails again with EPROTO, is retried, fails in the same way again, etc. "forever". I am not seeing this same behavior on a similarly configured Dell Optiplex desktop. Thus far, only on RPi. Question: have you seen such behavior? Had you considered adding EPROTO to the list of urb->status errnos failed rather than retried? If I do fail, rather than retry, the -EPROTO-failed URB, I get my expected results. I do not know what the correct approach is, hoped you could opine: should I add EPROTO as a "fail" rather than as a "retry" error in usb_serial_generic_read_bulk_callback() (this seems to fix my problem)? Or should I investigate why/where the EPROTO is coming from vs. why it is not, say, ENOENT (it does not seem unreasonable to retry an EPROTO IFF EPROTO is considered transient, however my test case it seems to get "stuck at" EPROTO)? Thoughts appreciated, thank you, ~Mark Mark Enstone "We are stuck with technology when what we really want is just stuff that works" --- DNA -- 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
