From: Julius Werner <jwerner@chromium.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
Alan Stern <stern@rowland.harvard.edu>,
Sarah Sharp <sarah.a.sharp@linux.intel.com>,
Andiry Xu <andiry.xu@amd.com>,
Vincent Palatin <vpalatin@chromium.org>,
Benson Leung <bleung@chromium.org>,
Julius Werner <jwerner@chromium.org>
Subject: [PATCH] usb: core: don't try to reset_device() a port that got just disconnected
Date: Tue, 30 Jul 2013 10:08:10 -0700 [thread overview]
Message-ID: <1375204090-27465-1-git-send-email-jwerner@chromium.org> (raw)
The USB hub driver's event handler contains a check to catch SuperSpeed
devices that transitioned into the SS.Inactive state and tries to fix
them with a reset. It decides whether to do a plain hub port reset or
call the usb_reset_device() method based on whether there was a device
attached to the port.
However, there are device/hub combinations (found with a JetFlash
Transcend mass storage stick (8564:1000) on the root hub of an Intel
LynxPoint PCH) which can transition to the SS.Inactive state on
disconnect (and stay there long enough for the host to notice). In this
case, above-mentioned reset check will call usb_reset_device() on the
now disconnected device. This leads to a futile attempt of asking a
bunch of floating wires to disable device-initiated U1 and U2, each
stalling khubd for a 5 second timeout before finally accepting the
device's fate amongst a flurry of error messages.
This patch makes the choice of reset dependent on the port status that
has just been read from the hub, as opposed to any previous in-kernel
state, thus working around this problem.
Signed-off-by: Julius Werner <jwerner@chromium.org>
---
drivers/usb/core/hub.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 4a8a1d6..ace0c52 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4798,7 +4798,7 @@ static void hub_events(void)
hub->ports[i - 1]->child;
dev_dbg(hub_dev, "warm reset port %d\n", i);
- if (!udev) {
+ if (!(portstatus & USB_PORT_STAT_CONNECTION)) {
status = hub_port_reset(hub, i,
NULL, HUB_BH_RESET_TIME,
true);
@@ -4808,8 +4808,8 @@ static void hub_events(void)
usb_lock_device(udev);
status = usb_reset_device(udev);
usb_unlock_device(udev);
+ connect_change = 0;
}
- connect_change = 0;
}
if (connect_change)
--
1.7.12.4
next reply other threads:[~2013-07-30 17:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-30 17:08 Julius Werner [this message]
2013-07-30 17:14 ` Julius Werner
2013-07-30 17:30 ` Alan Stern
2013-07-31 2:33 ` Julius Werner
2013-07-31 14:49 ` Alan Stern
2013-07-31 18:49 ` Julius Werner
2013-07-31 16:05 ` Sarah Sharp
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=1375204090-27465-1-git-send-email-jwerner@chromium.org \
--to=jwerner@chromium.org \
--cc=andiry.xu@amd.com \
--cc=bleung@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=sarah.a.sharp@linux.intel.com \
--cc=stern@rowland.harvard.edu \
--cc=vpalatin@chromium.org \
/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
all inboxes | Powered by JetHome®