On Wed, 15 Feb 2012, Sarah Sharp wrote: > On Wed, Feb 15, 2012 at 10:48:05AM -0500, Alan Stern wrote: > > On Wed, 15 Feb 2012, Elric Fu wrote: > > > > > Hi all, > > > > > > I found a usb 3.0 hub issue. Now I use a NEC xHCI host card and a VIA VL810 3.0 > > > hub to test suspend/resume function. I found the device attached to a usb 3.0 > > > hub port didn't respond the address device command in the procedure of > > > re-enumeration after resume. I tested linux kernel from 2.6.39 to 3.1.0+. All > > > of them have the issue. > > > > > Then I found the root cause by USB CATC. USB core sends a set hub > > > depth request to > > > usb 3.0 hub in hub_configure() in superspeed hub initialization. And > > > If we do a s3/s4, > > > after resume usb core should reset the device and send the set hub > > > depth request > > > again. But before re-enumeration the usb core doesn't do it. So I > > > added a set hub depth > > > request after setting configuration in usb_reset_and_verify_device(). > > > Now it seems like > > > the issue is gone. > > > > Assuming this is the right thing to do, the place to do it is in > > hub_activate(), not usb_reset_and_verify_device(). > > It might be the right thing to do for this particular hub, but it means > the hub is very broken. Any USB device is supposed to respond to the > Set Address command once it's link trained. It shouldn't matter when we > send the set hub depth request, as long as we do so before we start > using it as a hub. You're missing the point. We send the Set-Depth request in hub_configure(), which runs only once when the hub is first bound to the hub driver. We do not send it when the hub is reset, in the HUB_POST_RESET or HUB_RESET_RESUME cases of hub_activate(). Therefore the correct solution is to move the code that sends the Set-Depth request into hub_activate(), so that it will run on either an init or reset path. 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
