--- On Wed, 2/9/11, Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote: > > Oh, I see. Lubin, was this a USB 3.0 device? Yes, it is. > If > so, the re-enumeration > process would have skipped the second reset because it > thought this was > an initial device connect. Yes, this is what I saw in the code. > Is there anyway to tell that the device is undergoing > re-enumeration > because the descriptor changed? I don't know, but again I haven't dug in there either. If if there were, a brand new allocated device seems to be given to hub_port_init() from hub_port_disconnect_change(), whose history is clean. Maybe inspect the port history if there's such a thing... There are other protocols whose host stacks preserve the device over a disconnect, unless the device is a different device. SAS for example... > I vaguely recall some > field in the > usb_device structure for that... 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. I think that seems like the easiest solution for now. I'm testing something like that now. Reading the hub.c code I'd wish for more formalism regarding the device state and device state transitions. However I doubt that'll ever change. Whatever you come up with, please post it and I'll test it here as well. 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
