On Wed, 9 Feb 2011, Sarah Sharp wrote: > > 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. > > Oh, I see. Lubin, was this a USB 3.0 device? If so, the re-enumeration > process would have skipped the second reset because it thought this was > an initial device connect. > > Is there anyway to tell that the device is undergoing re-enumeration > because the descriptor changed? I vaguely recall some field in the > usb_device structure for that... No, you must be thinking of something else. The old device structure gets destroyed and there's no indication in the new device structure of anything unusual. > If not, I'll just have to make the hub > code always reset USB 3.0 devices, which will slow down initial > connections and booting over USB 3.0. 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? 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. Perhaps xhci-hcd should always ignore Set-Address requests from usbcore and automatically issue its own requests following initial link training and resets. 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
