We can't halt the secondary HCD, because it's also the primary HCD, which will cause problems if we have devices attached to the primary HCD, like a keyboard. --- Not yet signed-off because I am waiting for some kexec testing to be done on another environment, and I would like to bring this into a discussion to maybe come up with a better solution, or confirm this is OK. And probably most of this message should go into the commit log anyway. We have a USB 3.0 card using a TI chip and it doesn't behave very well when we halt it while it still has some pending URBs. We have to disconnect both the USB 3.0 and USB 2.0 devices from the host before we halt. XHCI PCI always create a primary and secondary HCDs, in the form of shared_hcd. The USB 2.0 roothub is created first and removed last, and itÅ? the primary HCD. The USB 3.0 roothub is the shared_hcd. The removal calls usb_remove_hcd for the shared_hcd and hsb_hcd_pci_remove for the primary HCD. Ultimately, usb_hcd_pci_remove calls usb_remove_hcd. usb_remove_hcd disconnects the connected devices and calls XHCI stop. xhci_stop will call xhci_only_stop_hcd for the secondary (ie, shared_hcd, which is the USB 3.0 roothub), which calls xhci_halt, and for the USB 2.0 roothub, it will call xhci_halt and do the rest of the cleanup. What seems to happen for the TI chip is that while the HID device is still connected (ie, we still have pending URBs on the queue), halting is not a great idea. And as described above, what is done right now is: 1) disconnect USB 3.0 devices 2) halt 3) disconnect USB 2.0 devices 4) halt and cleanup What I do is avoid halting before we disconnect the USB 2.0 devices. We know that xhci_only_stop_hcd is only called for the secondary for which there is a primary with the same xhci. Much of that information is on the xhci driver itself, so we are not working around the upper layer more than the driver already is. One option we have to be too much invasive here with other chipsets is skip the halt only for the TI host card, by using a new quirk. Regards. Cascardo. --- drivers/usb/host/xhci.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 924a6cc..3fdf8a9 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -651,7 +651,12 @@ static void xhci_only_stop_hcd(struct usb_hcd *hcd) struct xhci_hcd *xhci = hcd_to_xhci(hcd); spin_lock_irq(&xhci->lock); - xhci_halt(xhci); + /* + * We can't halt the secondary HCD, because it's also the + * primary HCD, which will cause problems if we have devices + * attached to the primary HCD, like a keyboard. + */ + /*xhci_halt(xhci);*/ /* The shared_hcd is going to be deallocated shortly (the USB core only * calls this function when allocation fails in usb_add_hcd(), or -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
