From: Bin Liu <b-liu@ti.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: <linux-usb@vger.kernel.org>
Subject: Re: [PATCH] usb: musb: return -ESHUTDOWN in urb when three-strikes error happened
Date: Thu, 14 May 2020 12:00:23 -0500 [thread overview]
Message-ID: <20200514170023.GD11463@iaqt7> (raw)
In-Reply-To: <20200514162604.GA9571@rowland.harvard.edu>
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@ti.com>
> > > > > >
> > > > > > 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.
next prev parent reply other threads:[~2020-05-14 17:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-13 21:36 [PATCH] usb: musb: return -ESHUTDOWN in urb when three-strikes error happened Bin Liu
2020-05-14 1:32 ` Alan Stern
2020-05-14 14:28 ` Bin Liu
2020-05-14 14:40 ` Alan Stern
2020-05-14 15:02 ` Bin Liu
2020-05-14 15:37 ` Bin Liu
2020-05-14 16:26 ` Alan Stern
2020-05-14 17:00 ` Bin Liu [this message]
2020-05-14 18:55 ` Alan Stern
2020-05-19 17:12 ` Bin Liu
2020-05-19 20:01 ` Alan Stern
2020-05-20 14:31 ` Bin Liu
2020-05-20 16:40 ` Alan Stern
2020-05-20 18:05 ` Bin Liu
2020-05-20 18:25 ` Alan Stern
2020-05-20 18:59 ` Bin Liu
2020-05-19 17:28 ` [PATCH v2] " Bin Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200514170023.GD11463@iaqt7 \
--to=b-liu@ti.com \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).