On Wed, 14 Nov 2012, Sarah Sharp wrote: > On a device connect, the port can go into either Compliance Mode or > Inactive on various link failures. Also, the ports can change state > into Inactive if the U1/U2 exit fails. So if we have Link PM enabled > for a USB 3.0 device, the port can go into Inactive at any time. > Therefore we need to be able to handle both Inactive and Compliance in > hub_events.
I see. To answer your original question: If a reset is needed at some random time in hub_events(), say because of a link state transition failure, then yes -- you do need to go through the whole pre-reset/post-reset thing. In practice the best approach is simply to call usb_reset_device(). That calls through hub_port_init() to hub_port_reset(), which would then have to be smart enough to figure what sort of reset was needed. > > The cleanup certainly looks worthwhile, but I didn't do a detailed > > review. The changes are too big and far-reaching to be understood just > > by reading the patch. > > Yes, it's a fundamental change to the port handling code. I do want to > get it into stable, because other people are likely to run into this > issue, but I'm really concerned about the amount of code changes. Maybe > it shouldn't be marked for stable at all? Maybe not. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
