On Thu, May 14, 2020 at 12:26:04PM -0400, Alan Stern wrote: > On Thu, May 14, 2020 at 10:37:31AM -0500, Bin Liu wrote: > > On Thu, May 14, 2020 at 10:02:59AM -0500, Bin Liu wrote: > > > On Thu, May 14, 2020 at 10:40:53AM -0400, Alan Stern wrote: > > > > On Thu, May 14, 2020 at 09:28:03AM -0500, Bin Liu wrote: > > > > > On Wed, May 13, 2020 at 09:32:05PM -0400, Alan Stern wrote: > > > > > > On Wed, May 13, 2020 at 04:36:20PM -0500, Bin Liu wrote: > > > > > > > When a USB device attached to a hub got disconnected, MUSB controller > > > > > > > generates RXCSR_RX_ERROR interrupt for the 3-strikes-out error. > > > > > > > > > > > > > > Currently the MUSB host driver returns -EPROTO in current URB, then the > > > > > > > USB device driver could immediately resubmit the URB which causes MUSB > > > > > > > generate RXCSR_RX_ERROR interrupt again. This circle causes interrupt > > > > > > > storm then the hub never got a chance to report the USB device detach. > > > > > > > > > > > > > > To fix the interrupt storm, change the URB return code to -ESHUTDOWN for > > > > > > > MUSB_RXCSR_H_ERROR interrupt, so that the USB device driver will not > > > > > > > immediately resubmit the URB. > > > > > > > > > > > > > > Signed-off-by: Bin Liu <b-liu@xxxxxx> > > > > > > > > > > > > Strictly speaking, this is not the right thing to do. It goes against > > > > > > the API described in error-codes.rst. A better approach would be to fix > > > > > > > > > > error-codes.rst says: > > > > > > > > > > -ESHUTDOWN The device or host controller has been > > > > > disabled due to some problem that could not > > > > > be worked around, such as a physical > > > > > disconnect. > > > > > > > > > > So -ESHUTDOWN is applicable in this case - the device is disconnected > > > > > behind a hub. > > > > > > > > Yes, but you don't _know_ that the device was disconnected. All you > > > > know is that there was a 3-strikes error. Other problems can cause such > > > > errors (noise, for example). > > > > > > Yes, I know this. But we don't have a solution then. I cannot add > > > resubmit delay in those ~500 device drivers. > > > > By the way I don't think noise could last long enough to cause 3-strikes > > error. A shortest USB packet is about 3-bytes long, a noise should be > > just a glitch, it won't last at least 3-bytes long to supress the bus > > and 3 times on the exact timing when the host expecting a response > > packet. I cannot think of any other reason which can cause the 3-strikes > > error other than the device is off the bus. > > Heh. I heard from somebody (many years ago) about a setup where one of > his USB devices stopped working whenever he turned on the fluorescent > lights. This could happen, noise comming in from the power supply, cheap power supply and poor board design. > Yes, I agree that noise is pretty uncommon, and the vast majority of > 3-strikes errors are caused by disconnection or device firmware bugs. I wasn't mean noise is uncommon, it is just it won't cause 3-strikes error because the glitch is very short. I have seen many cases that noise causing issues on MUSB due to poor board design especially on those USB modem or WIFI projects. > That's why I didn't NAK this patch. Thanks. > Still, it's worth pointing out that this change abuses the API (perhaps > mentioning it in a comment). And it still would be preferable to fix Okay, I will add those notes in comment in v2. > the drivers in question, impractical though that may be. (I have a hard > time believing there are really 500 of them getting this wrong...) I am not sure about it either, but yeah it is not practical to fix the issue in device drivers. So far I have seen 3 reports of this issue: 1. with FTDI usb-serial adapter, the issue is in the usb serial generic driver; 2. with a modem, the issue is in usb wwan driver as I fixed in the patch I sent yesterday; 2. another modem, before I was able to locate the offending device driver, the guy who reported the issue disappeared, and not responding me. -Bin.
