On Fri, 2011-05-06 at 05:29 +0800, Alan Stern wrote: > On Thu, 5 May 2011, Sarah Sharp wrote: > > > On Thu, May 05, 2011 at 06:14:11PM +0800, Andiry Xu wrote: > > > From: Alex He <alex.he@xxxxxxx> > > > > > > This is a new TRB Completion Code of the xHCI spec 1.0. > > > Asserted if the xHC detects a problem with a device that does not > allow it to > > > be successfully accessed, e.g. due to a device commpliance or > compatibility > > > problem. This error may be returned by any command or transfer, > and is fatal > > > as far as the Slot is concerned. Software shall issue a Disable > Slot Commmand > > > to recover. > > > > How is the upper layer supposed to know the slot is now disabled? > It > > seems like a policy violation to let the xHCI driver just randomly > > disable devices. Shouldn't you let the USB core decide whether it > needs > > to logically disconnect the device and disable the slot? Sure. The best way is to let the usb core to decide how to do this case. > > > > You say we can get this error code on any command. What happens if > we > > get this error for something like a Configure Endpoint command while > the > > USB core is trying to set a new alternate interface setting. The > call > > to usb_hcd_alloc_bandwidth() is going to fail, and the device driver > > will just assume the set interface command failed. But it can still > try > > to talk to the control endpoint, which suddenly will start failing. > > > > Meanwhile, the USB core thinks the device still exists, but it's > > basically dead to the xHCI driver. Plus, if there's URBs in flight > when > > we receive this command completion code, the xHCI driver is going to > try > > to free the endpoint rings when the disable slot command finishes. > That > > seems very bad. > > > > Maybe it would be better to just return -ENODEV in this case and let > the > > USB core disable the device? > That sounds right, except that URBs with low-level communication > errors > should complete with an error code of -EPROTO or -EILSEQ (there's not > much difference between the two). > The slot will be disabled when the device is disconnected. But the error value of handle_tx_event() or handle_cmd_completion() in xhci_irq() can't be transfered to the USB core level. Even the return type of the handle_cmd_completion() is void.So I make the xhci driver to do the disable slot command. Do you have other way to info the USB core about it? > > 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 > > > -- 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
