[adding musb maintainer Felipe Balbi to this discussion] On Tue, Aug 11, 2015 at 2:25 PM, Oliver Neukum <oneukum@xxxxxxxx> wrote: > On Tue, 2015-08-11 at 13:48 +0200, Bjørn Mork wrote: >> I wonder if this is related to different platforms using different >> errors for this event? As you can see, I get ESHUTDOWN where you got >> EPROTO. The driver resubmits the URB in the EPROTO case. And that's >> probably why you end up with a dead system. Although I would have >> thought that the submit should immediately return an error, the fact >> that you get multiple error messages for the same device proves that >> the >> resubmit results in the callback being executed. I guess it ends up >> in >> a tight resubmit loop. > > That is possible. >> >> I hope some of the USB experts can tell us what the correct behaviour >> is >> here. Should the driver treat EPROTO like ESHUTDOWN? Or should the >> host controller use some ESHUTDOWN instead? > > No. ESHUTDOWN is reserved for the removal of the HC. > > What errors a driver gets talking to a removed device is > not defined and depends in part on the hardware involved. > Some of these errors may be genuine. >> >> If so, what about other errors? If the assumptions above are correct, >> then it seems that any unhandled persistent error can send the driver >> into a hard loop. That doesn't seem right... > > The driver that does handle it in an exemplary manner is HID. > > You ought to limit the number of immediate retries to a very low > number, then use a timer with exponential backoff and then proceed > to reset, if applicable. > > Detection of a hot unplug is not immediate. It may take a few hundred > ms. > > HTH > 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
