On Mon, 16 Sep 2013, Huang Rui wrote: > Hi Greg, 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. > > 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. > > [Q] Why the special devices are only mice? Would high speed devices > such as 3G modem or USB Bluetooth adapter trigger this issue? > - Current this sensitivity is only confined to devices that use Pixart > controllers. This controller is designed for use with LS mouse > devices only. We have not observed any other devices failing. There > may be a small risk for other devices also but this patch (reset > device in resume phase) will cover the cases if required. > > [Q] Shouldn’t the resume signal be sent within 100 us for every > device? > - The Host controller may not send the resume signal within 100us, > this our host controller specification change. This is why we > require the patch to prevent side effects on certain known devices. > > [Q] Why would clicking mouse INTENSELY to wake the system up trigger > this issue? > - This behavior is specific to the devices that use Pixart controller. > It is timing dependent on when the resume event is triggered during > the sleep state. > > [Q] Is it a host controller issue or mouse? > - It is the host controller behavior during resume that triggers the > device incorrect behavior on the next resume. > > - Patch 1 refactors AMD quirk to abstract chipset types. > - Patch 2 implements AMD remote wakeup quirk. > They are generated on gregkh/usb usb-next. > > Changes from v1 -> v2: > - Add reproduce steps. > - Add a patch to put the changes of core/hub.c and pci-quirks into one > patch. > - Remove all the split strings. > - Refactor usb_amd_remote_wakeup_quirk to save a variable and less > codes. > - Remove 10ms delay in spinlock during xhci reset port by mouse. > - Add an extra tab to algin to all quirks macros. > - Remove backport request. > - Add descriptions of the fixes and how they work. > - Summarized questions from Sarah and Alan. > > Changes from v2 -> v3: > - Split first patch into two, the one add all the issue USB mice with > vendor id and product id in core/quirk.c, the other one is for filtering > the special AMD platforms. > - Remove is_usb_mouse function, as Greg required that don't use device type > for filtering. > > Changes from v3 -> v4: > - Refactor AMD pci quirk to abstract out chipset types to list generation > with a enumeration type and revision as Greg's suggestion. > - Remove xhci and ohci level codes. > - Implement remote wakeup quirk at core level as Alan's suggestion. This version of the patch set looks good. 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
