On Fri, 6 Sep 2013, Huang Rui wrote:
> The following patch is 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.
>
> Workaroud:
> 1. Filter the special platforms, then judge of all the usb devices are
> mouse or not. And get out the port id which attached a mouse with Pixart
> controller.
> 2. Then reset the port which attached issue device during system resume
> from S3.
>
> [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.
>
> This patch is for OHCI driver to add AMD remote wakeup fix.
>
> Signed-off-by: Huang Rui <[email protected]>
> ---
> drivers/usb/host/ohci-hub.c | 45
> +++++++++++++++++++++++++++++++++++++++++++++
> drivers/usb/host/ohci-pci.c | 14 ++++++++++++++
> drivers/usb/host/ohci.h | 23 ++++++++++++-----------
> 3 files changed, 71 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/usb/host/ohci-hub.c b/drivers/usb/host/ohci-hub.c
> index 2347ab8..5a95c75 100644
> --- a/drivers/usb/host/ohci-hub.c
> +++ b/drivers/usb/host/ohci-hub.c
> @@ -41,6 +41,7 @@
>
> static void dl_done_list (struct ohci_hcd *);
> static void finish_unlinks (struct ohci_hcd *, u16);
> +static inline int root_port_reset (struct ohci_hcd *, unsigned);
>
> #ifdef CONFIG_PM
> static int ohci_rh_suspend (struct ohci_hcd *ohci, int autostop)
> @@ -293,6 +294,47 @@ static int ohci_bus_suspend (struct usb_hcd *hcd)
> return rc;
> }
>
> +/*
> + * Reset port which attached with an issue device.
> + *
> + * 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.
> + *
> + * 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 usb mouse controller would react
> + * differently to this unexpected event from some AMD host controller
> + * and will result in the mouse to assert a resume event on the
> + * subsequent S3 sleep even if the user does not initiate the wake
> + * event by clicking on the mouse. So it should reset the port which
> + * attached with issue mouse during S3 reusme phase.
> + */
> +static int ohci_reset_port_by_amd_remote_wakeup(struct ohci_hcd *ohci)
> +{
> + u32 temp;
> + struct usb_device *hdev, *child;
> + int port1, wIndex;
> +
> + hdev = hcd_to_bus(ohci_to_hcd(ohci))->root_hub;
> +
> + usb_hub_for_each_child(hdev, port1, child) {
> + wIndex = port1 - 1;
> + temp = roothub_portstatus(ohci, wIndex);
> + dbg_port(ohci, "Get port status", wIndex, temp);
> + if (is_issue_device_for_amd_quirk(child)) {
> + ohci_dbg(ohci, "Connencted issue device on port %d.\n",
> + wIndex);
> + root_port_reset(ohci, wIndex);
> + }
> + }
> +
> + return 0;
> +}
This really is not the right way to do what you want.
What you ought to do is set the USB_QUIRK_RESET_RESUME flag for these
Pixart-based mice when they are attached to an AMD controller with the
resume bug. Therefore you should create a new flag inside the usb_hcd
structure:
unsigned amd_resume_bug:1;
You can set this flag during OHCI or xHCI probing. Then you can add
a special routine in drivers/usb/core/quirks.c to set the RESET_RESUME
quirk for Pixart-based devices if udev->level == 1 (the device is
attached directly to the root hub) and the hcd has the amd_resume_bug
flag set.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
