On Sat, Sep 07, 2013 at 12:08:27AM +0800, Alan Stern wrote:
> 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 <ray.huang@xxxxxxx>
> > ---
> > 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.
>
Hi Alan,
Thank you to teach me. :)
I will refactor my patches as you suggested.
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
