On Mon, 2 Jun 2014, vichy wrote: > hi Greg: > > 2014-05-31 0:02 GMT+08:00 Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>: > > On Fri, May 30, 2014 at 11:28:36PM +0800, che-chun Kuo wrote: > >> We found when we plug in/out usb3.0 device for stress testing, once > >> usb_get_device_descriptor fail in hub_port_init, we will call hub_port_disable. > >> Then usb3.0 device may not recover successfully with only hot reset like below function > >> retval = hub_port_reset(hub, port1, udev, delay, false); > >> > >> For covering this error handling, we add warm reset if getting device descriptor fail on usb3.0 devices. > > > > Odd linewrapping :( > since I try to make the explanation more readable, I purposely add > more blank like. > sorry for making you confused. ^^ > > > > Anyway, what makes USB 3 devices so "special" here that they need a > > reset vs. all other devices? > in the beginning, I try to add quirk determination in usb driver. > But get descriptor is the 1st command we get. > if getting descriptor fail, I have no idea how to add quirk > determination in usb driver. > > > > > Are you sure your device isn't just broken somehow? > Yes, your concern is reasonable. > for accelerating the issue happen, I purposely create diff at the end of mail. > And I try 5 devices on my hand, 2 of them will not successfully return > back with only hot reset. > > In usb3.0 spec, warm reset will force usb3.0 jump to Rx.detect. > But hot reset will direct down stream port from to ss.Disabled only > only if time out happen. > That is why I add warm reset when get device descriptor fail. Dan Williams should take a look at this patch. He has been doing lots of similar stuff lately involving warm 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
