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