From: Greg KH <gregkh@suse.de>
To: torvalds@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
Sarah Sharp <sarah.a.sharp@linux.intel.com>,
stable@kernel.org
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Randy Dunlap <rdunlap@xenotime.net>
Subject: [patch 2/3] USB: xhci: Set change bit when warm reset change is set.
Date: Mon, 19 Sep 2011 16:05:11 -0700 [thread overview]
Message-ID: <20110919230833.469891151@clark.kroah.org> (raw)
In-Reply-To: <20110919230920.GA6555@kroah.com>
Sometimes, when a USB 3.0 device is disconnected, the Intel Panther Point
xHCI host controller will report a link state change with the state set
to "SS.Inactive". This causes the xHCI host controller to issue a warm
port reset, which doesn't finish before the USB core times out while
waiting for it to complete.
When the warm port reset does complete, and the xHC gives back a port
status change event, the xHCI driver kicks khubd. However, it fails to
set the bit indicating there is a change event for that port because the
logic in xhci-hub.c doesn't check for the warm port reset bit.
After that, the warm port status change bit is never cleared by the USB
core, and the xHC stops reporting port status change bits. (The xHCI spec
says it shouldn't report more port events until all change bits are
cleared.) This means any port changes when a new device is connected will
never be reported, and the port will seem "dead" until the xHCI driver is
unloaded and reloaded, or the computer is rebooted. Fix this by making
the xHCI driver set the port change bit when a warm port reset change bit
is set.
A better solution would be to make the USB core handle warm port reset in
differently, merging the current code with the standard port reset code
that does an incremental backoff on the timeout, and tries to complete the
port reset two more times before giving up. That more complicated fix
will be merged next window, and this fix will be backported to stable.
This should be backported to kernels as old as 3.0, since that was the
first kernel with commit a11496ebf37534177d67222285e8debed7a39788
"xHCI: warm reset support".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/usb/host/xhci-hub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -761,7 +761,7 @@ int xhci_hub_status_data(struct usb_hcd
memset(buf, 0, retval);
status = 0;
- mask = PORT_CSC | PORT_PEC | PORT_OCC | PORT_PLC;
+ mask = PORT_CSC | PORT_PEC | PORT_OCC | PORT_PLC | PORT_WRC;
spin_lock_irqsave(&xhci->lock, flags);
/* For each port, did anything change? If so, set that bit in buf. */
next prev parent reply other threads:[~2011-09-19 23:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-19 23:09 [patch 0/3] Staging and USB fixes for 3.1 Greg KH
2011-09-19 23:05 ` [patch 1/3] staging: fix comedi build when ISA_DMA_API is enabled but COMEDI_PCI is not enabled Greg KH
2011-09-19 23:05 ` Greg KH [this message]
2011-09-20 11:22 ` [patch 2/3] USB: xhci: Set change bit when warm reset change is set Sergei Shtylyov
2011-09-20 12:58 ` Greg KH
2011-09-19 23:05 ` [patch 3/3] USB: xHCI: prevent infinite loop when processing MSE event Greg KH
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=20110919230833.469891151@clark.kroah.org \
--to=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=sarah.a.sharp@linux.intel.com \
--cc=stable@kernel.org \
--cc=torvalds@linux-foundation.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
Powered by JetHome