--- On Wed, 2/9/11, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>
> It can't get any worse than USB 2.0 already is, which isn't
> so
> terrible. On the other hand, why did xhci-hcd try to
> send the second
> Set-Address request?
Because it kicked khubd, see below for the code sequence.
> As I understand it, the driver
> knows that
> Set-Address is required:
>
> following initial device detection, or
>
> following a reset.
>
> Neither of these was true here.
There was a hot reset. The device transitioned to the Default state. The
xhci driver sent SET ADDRESS, the device transitioned to the Addressed
state. This is the sequence from the host (Linux):
usb_reset_and_verify_device()
hub_port_init()
hub_set_address()
SET_ADDRESS 0->1 (value printed in the kernel log is always different than actual value, 1)
usb_get_device_descriptor(udev, 8)
usb_get_device_descriptor(udev, 18)
descriptors_changed() --> goto re_enumerate:
hub_port_logical_disconnect()
kick_khubd()
Then khubd did this:
hub_events()
hub_port_connect_change()
usb_disconnect()
usb_disable_device()
new device struct
sets device state to Powered
choose_address()
hub_port_init() <-- no reset, issue SET ADDRESS 0->1
The new device allocated has no history and another SET ADDRESS to addr 0
is sent, which gets dropped on the floor, as the device is already
in the Addressed state with address 1 _because_ there was no reset since.
A 2nd reset is necessary with the code as it is written just like with
USB 2.0.
> Perhaps xhci-hcd
> should always ignore
> Set-Address requests from usbcore and automatically issue
> its own
> requests following initial link training and resets.
This seems to be the case. Another quirk is that "devnum" is never the
same as the address the device gets.
Luben
--
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
