USB: EHCI: unlink QHs even after the controller has stopped

Old code in ehci-hcd tries to expedite disabling endpoints after the
controller has stopped, by destroying the endpoint's associated QH
without first unlinking the QH.  This was necessary back when the
driver wasn't so careful about keeping track of the controller's
state.

But now we are careful about it, and the driver knows that when the
controller isn't running, no unlinking delay is needed.  Furthermore,
skipping the unlink step will trigger a BUG() in qh_destroy() when the
preceding QH is released, because the link pointer will be non-NULL.

Removing the lines that skip the unlinking step and go directly to
QH_STATE_IDLE fixes the problem.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Joe Lawrence <joe.lawrence@stratus.com>
Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 81cda09b47e3127772e51cbc5c57eab7761c4a52..488a30836c36cbee57f2e16f7813db7075891699 100644 (file)
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -965,8 +965,6 @@ rescan:
        }
 
        qh->exception = 1;
-       if (ehci->rh_state < EHCI_RH_RUNNING)
-               qh->qh_state = QH_STATE_IDLE;
        switch (qh->qh_state) {
        case QH_STATE_LINKED:
                WARN_ON(!list_empty(&qh->qtd_list));