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? > > 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. 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
