On Fri, 13 Apr 2012, Xu, Andiry wrote: > > To trigger the race, add an ssleep(2) call (or something similar) to > > the end of xhci_bus_suspend. Plug in a SuperSpeed hub, and attach some > > other SuperSpeed device to the hub. > > > Then start a system suspend. During the elay caused by the ssleep > > call, unplug the device from the hub. That should cause the hub to > > generate a remote wakeup request, and if your patch works correctly > > then the wakeup request will cause the system suspend to be aborted. > > I have doubt about this. Note xHCI has different remote wakeup mechanism > for 3.0 port and 2.0 port. For 2.0 port, it's almost the same as EHCI: write resume > state to PORTSC register and waiting for 20ms, then write U0 to the register. > For SS port, it does not have this "20ms clock" mechanism, just write U0 to the > register. The code change in the patch mainly cover the 2.0 port part. For 3.0 > port behavior, I doubt there will be any difference with the patch. Or should I > use a 2.0 hub and 2.0 device to verify the patch? Oh, I see. Yes, you're right; you should test the non-SuperSpeed case. I guess the speed of the hub doesn't matter, but the device definitely should not be SuperSpeed. 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
