--- On Wed, 2/9/11, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, 9 Feb 2011, Sarah Sharp
> wrote:
>
> > I have never tried to reset a USB device under xHCI
> via usbfs, so that's
> > probably why it never showed up. Thanks for
> catching this.
>
> usbfs doesn't do anything special. It simply calls
> usb_reset_device().
>
> Probably the reason you never saw this error scenario
> before is that
> you never tried updating the firmware in a device. In
> particular, when
> the descriptors get changed the entire device structure is
> destroyed,
> then the device has to be reset a second time and
> re-enumerated.
> Apparently this fools xhci-hcd into thinking the device was
> never
> assigned an address when in fact it was. Maybe the
> second reset got
> skipped.
Here it is, in hub_port_init():
if (!udev->config && oldspeed == USB_SPEED_SUPER) {
/* Don't reset USB 3.0 devices during an initial setup */
usb_set_device_state(udev, USB_STATE_DEFAULT);
} else {
The sequence of events looks like this:
usb_reset_and_verify_device()
hub_port_init()
hub_set_address()
SET_ADDRESS (value printed in the kernel log is always different than actual value)
usb_get_device_descriptor(udev, 8)
usb_get_device_descriptor(udev, 18)
descriptors_changed() --> goto re_enumerate:
hub_port_logical_disconnect()
kick_khubd()
hub_events()
hub_port_connect_change()
usb_disconnect()
usb_disable_device()
new device struct (!config is true)
sets device state to Powered
choose_address()
hub_port_init() <-- no reset, see above; issue SET ADDRESS to 0, no response as device is in Addressed state; bug.
Can Intel or an old boys club member submit a patch to fix this? Shouldn't be that difficult given the above.
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
