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. > 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. > 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? Thanks, Rui -- 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
