On Mon, Jan 27, 2014 at 10:52:48AM -0500, Alan Stern wrote:
> On Mon, 27 Jan 2014, Peter Chen wrote:
>
> > If the high-speed device does not enter full-speed idle after
> > wakeup on disconnect logic has effected, there will be an
> > unexpected disconnect wakeup interrupt due to the bus is still SE0.
>
> I think you mean "If the high-speed device does not enter full-speed
> idle _before_ wakeup on disconnect logic has taken effect..."
Yes, thanks.
>
> It sounds like this is a bug in your EHCI hardware. The
> wake-on-disconnect logic should never take effect until after the port
> goes into full-speed idle.
Where EHCI spec said that? I can't find it at 2.3.9 and 4.3.
>
> > Signed-off-by: Peter Chen <peter.chen@xxxxxxxxxxxxx>
> > ---
> >
> > Changes for v2:
> > Using usleep_range instead of mdelay
> >
> > drivers/usb/host/ehci-hub.c | 12 ++++++++++++
> > 1 files changed, 12 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
> > index 47b858f..976294c 100644
> > --- a/drivers/usb/host/ehci-hub.c
> > +++ b/drivers/usb/host/ehci-hub.c
> > @@ -301,6 +301,18 @@ static int ehci_bus_suspend (struct usb_hcd *hcd)
> >
> > if (t1 != t2) {
> > ehci_writel(ehci, t2, reg);
> > + if ((t2 & PORT_WKDISC_E)
> > + && (ehci_port_speed(ehci, t2) ==
> > + USB_PORT_STAT_HIGH_SPEED)) {
> > + /*
> > + * If the high-speed device has not switched
> > + * to full-speed idle before WKDISC_E has
> > + * effected, there will be a WKDISC event.
> > + */
> > + spin_unlock_irq(&ehci->lock);
> > + usleep_range(3500, 4000);
> > + spin_lock_irq(&ehci->lock);
> > + }
>
> This doesn't look like it will do what you want. t2 already has the
> PORT_WKDISC_E bit set, so once the
>
> ehci_writel(ehci, t2, reg);
>
> has executed, it is already too late. Instead, you should write (t2 &
> ~PORT_WKDISC_E), then wait a few ms, and then write t2.
Yes, it is safe for writing suspendM first, wait 3-4ms, then write
PORT_WKDISC_E. The reason why my proposal change is ok is the wakeup logic
has still not taken effect before the PHY enters low power mode.
>
> Since this bug seems to affect only a few EHCI controllers, we should
> have a quirk flag for it. There's no need to make everybody wait 3.5-4
> ms just for the sake of a few pieces of buggy hardware.
>
OK, I will add the quirk if you can point me it is not a standard ehci
operation.
--
Best Regards,
Peter Chen
--
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
