On Tue, 29 Sep 2009, David Vrabel wrote:
> Sarah Sharp wrote:
> > When the host controller dies (e.g. it is removed from a PCI card slot),
> > the xHCI driver cannot expect commands to complete. The buggy code this
> > patch fixes would mark an URB as canceled and then expect the URB to be
> > completed when the stop endpoint command completed. That would never
> > happen if the host controller was dead, so the USB core would just hang in
> > the disconnect code.
> >
> > If the host controller died, and the driver asks to cancel an URB, free
> > any structures associated with that URB and immediately give it back.
> >
> [...]
> > + temp = xhci_readl(xhci, &xhci->op_regs->status);
> > + if (temp == 0xffffffff) {
> > + xhci_dbg(xhci, "HW died, freeing TD.\n");
>
> Is this test sufficient? What if the hardware is non-responsive but
> still present on the bus?
>
> Does the cancel request have a cancel response/ack from the hardware and
> if so can you add a timer while waiting for this? If the timer expires
> the hcd would run through all queues and complete (with an error) all urbs.
David is right. This isn't the way dead host controllers are handled
in the other HCDs.
The drivers test at some appropriate point for whether the controller
is still connected and alive (generally from within the IRQ handler,
the resume routine, and/or a watchdog timer routine). If it isn't, the
driver sets hcd->state to HC_STATE_HALT (to tell usbcore that the
controller is dead), possibly calls usb_hc_died(), resets the
controller hardware, and sets a private flag.
Routines involved in unlinking and giving back URBs check the private
flag. If it is set then they bypass the hardware and carry out the
software part of their job immediately.
Alan Stern
--
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
