On Thu, 11 Jun 2009, Pan, Jacob jun wrote:
> >> + if (hcd->self.root_hub->do_remote_wakeup) {
> >> + if (t1 & PORT_CONNECT) {
> >> + t2 |= PORT_WKOC_E | PORT_WKDISC_E;
> >> + t2 &= ~PORT_WKCONN_E;
> >> + } else {
> >> + t2 |= PORT_WKOC_E | PORT_WKCONN_E;
> >> + t2 &= ~PORT_WKDISC_E;
> >> + }
> >> + } else
>
> > Why is this change needed? Are your controllers non-compliant with the
> > spec, causing them to generate wakeup notifications at the wrong time?
>
> > The spec says, for example, that if PORT_WKCONN_E is set then a
> > suspended controller will generate a wakeup request when a connection
> > event occurs. But if the port was already connected then there is no
> > connection event.
>
> The change is indeed needed due to new features in our host
> controller HW which are beyond EHCI spec. Specifically, our host
> controller can put the internal phy into low power mode based on the
> state of the connection. With both wake on connect/disconnect set, it
> can not go to phy low power suspend.
Sounds like the hardware is badly designed. It doesn't make sense that
you can go to a low-power state when either one of the bits is set but
not when both of them are set.
> On the other side, I think it is also the right thing to do to enable
> only the appropriate wake bits.
No, it is not the right thing to do. In fact, it is a race. What
happens if the connect state changes between the time when you read the
port status and when you set the wakeup bits? You'd end up with the
wrong bit set.
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
