Hi Alan, Thank you to your comments. On Fri, Aug 23, 2013 at 12:51:44AM +0800, Alan Stern wrote: > On Thu, 22 Aug 2013, Huang Rui wrote: > > > Hi Sarah, Alan, > > > > The following patches are required to resolve remote wake issues with > > certain devices. > > > > Issue description: > > If the remote wake is issued from the device in a specific timing > > condition while the system is entering sleep state then it may cause > > system to auto wake on subsequent sleep cycle. > > > > Root Cause: > > Host controller rebroadcasts the Resume signal > 100 µseconds after > > receiving the original resume event from the device. For proper > > function, some devices may require the rebroadcast of resume event > > within the USB spec of 100µS. > > > > Without this quirk, some AMD platform doesn't hold the resume right > > away when there is a resume signal from LS device like mouse. So it > > should reset the port which attached with mouse. > > 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. > > Patch 1 is the implementation for xHCI driver. > > Patch 2 is the implementation for OHCI driver. > > They are generated on gregkh/usb usb-next. > > You should have put the changes to core/hub.c and pci-quirks into > a third patch, instead of mixing them in with the xHCI changes. > I got it, will do it in v2. 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
