On Tue, Jul 27, 2010 at 11:14:39AM -0400, Alan Stern wrote: > On Tue, 27 Jul 2010, Xu, Andiry wrote: > > > > That's not quite right. It tries to reset the device first. Only if > > > the reset fails does it free and re-initialize the device. > > > > > > > Yes, you are right, I didn't make it clearly. The hub driver will try to > > reset the device first. After several failures, it will assume the > > device is gone, then free and re-initialize the device. > > > > The hub driver will call hcd->driver->reset_device() to reset the > > device. Reset Device is a xHCI command to put a device in addressed or > > configured state into default state. However since the xHC is reset, the > > reset command will fail - all the slots are freed and disabled after xHC > > reset. The command failure will show "cannot reset HCD device state" > > messages. > > Why isn't the device already in the addressed state? Doesn't the xHC > controller detect the device and initialize it right after the xHC > reset completes? Is the problem just that there wasn't enough time? After the host controller is reset after the host resume fails, all the state it has about devices is gone. The xHCI host controller needs to be told to re-address each device (basically to go through the enumeration sequence again so it can get a slot ID and address the device). If xhci_reset_device() is called for a device that the xHC host doesn't know about, the call will fail because the usb_device's slot_id field is set to zero. Now, xhci_reset_device() could be changed to return success if the slot_id is set to zero. I'm not sure if that would be good for other error cases. > > After check, I think I may found the difference between EHCI and xHCI in > > device address choosing. In EHCI, the hub driver calls choose_address() > > to set the device address. Choose_address() uses find_next_zero_bit() to > > find an available address. So the devnum will increase every time, > > because bus->devnum_next is increased every time. However, xHCI does not > > call choose_address(). The USB device address is assigned by H/W, upon a > > successful address device command. xHCI driver then set the devnum to > > the value xHC returns, so it will always be the same value. > > I thought that might be the problem. The kernel can't handle addresses > that are chosen by the hardware; it wants to choose the address itself. > xhci-hcd should set the address to the value specified by the kernel > instead of telling the kernel what address the hardware used. So, you're saying that the xHCI driver should have an internal field for the real device address, and allow the kernel to think it assigned a different address? Sarah Sharp -- 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
