On Sat, 24 Aug 2013, Huang Rui wrote: > On Fri, Aug 23, 2013 at 10:53:38PM +0800, Alan Stern wrote: > > On Fri, 23 Aug 2013, Huang Rui wrote: > > > > > > What's special about LS devices? Or mice? Shouldn't the resume signal > > > > be sent within 100 us for every device? > > > > > > > > > > Yes, only mice would trigger this issue. > > > Reproduce steps: > > > 1. Enable remote wakeup for usb mouse. > > > 2. Execute S3. > > > 3. Click mouse _intensely_ (more than 10 times) to wake the system up. > > > 4. Then execute S3 again. > > > 5. Observe that the system auto wake up. > > > > > > Actually, I tested all the mice in my side, this issue existed. > > > > It sounds like a bug in the mice. The fact that no other devices have > > the same problem tends to support this view. > > > > It's not in the mice but in host controller. How do you know? You mentioned earlier that the mouse would not clear its wakeup request. But resuming a device is always supposed to clear its wakeup request; if this doesn't happen then the device is buggy. > > Do you really know for certain that the timing of the wakeup signal is > > what causes this to happen? > > > > I checked with HW guys in my side, and will feedback soon. > > > And do you know why it happens only with AMD controllers? Have you > > tested other types of controllers? > > > > Yes, I tested on Renesas controller, didn't encounter. And not all AMD > controllers has this issue, only in some special revisions. What about OHCI controllers? > > A much simpler solution would be to have the usbhid driver set the > > USB_QUIRK_RESET_RESUME flag whenever it probes a mouse. This would > > work for all of the HCDs, so none of them would need to be changed. > > > > Due to the controller issue, I think we only reset port attached on > mouse, not reset mouse itself. Am I right? They are the same thing -- resetting the mouse means resetting the mouse's USB port. 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