Wild guess, you don't see the same behavior on your desktop machine because it's a different hcd that sets the return value. What happens when you
On Tue, Apr 7, 2015 at 9:57 PM, Mark Enstone <mark.enst...@silabs.com> 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". > > 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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
