On Tue, Apr 07, 2015 at 06:57:09PM +0000, Mark Enstone wrote: > 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". Sounds like a bug in the host controller driver, reporting the incorrect error value. The RPI's USB controller is horrid, it's amazing it works at all... > 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)? -EPROTO means that there is an unknown USB error, or a bus specific error, so the host controller should stop sending those quickly. So again, I think there's something wrong with the controller, not the driver, it's correct for the driver to continue to submit the urb for that error as when the device is really removed, it will get a different error number, not EPROTO. Have you tried asking the authors of that host driver? thanks, greg k-h -- 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
