On Tue, 27 Jul 2010, Sarah Sharp wrote: > 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. It looks like the problem is the special-case test in hub_port_init(). It skips the reset if the device is new and is running at SuperSpeed. Clearly this is not the right criterion. I think the test should be moved down into xhci-hcd, which knows more about the true situation, and it should be fixed. What really matters is whether the hardware already knows about the device, not whether the device is new. (In fact, it is possible to have new devices that the hardware _does_ know about, and it is possible to have old devices that the hardware _doesn't_ know about.) What should happen, if the device isn't already known, is that the hardware should be told to discover it. And finally, what about USB-2.0 devices? Do they have the restrictions regarding resets? I imagine not, since they already work under xHCI with the current code. > > > 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? No. I'm saying that xhci-hcd's address_device callback should actually change the device's address to the value assigned by the kernel. Hmm, the Wireless USB core also seems to have its own ideas about addressing devices. It wouldn't be surprising if they end up causing trouble too. 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
