On 16 May 2003, Paul Fulghum wrote:
> Gack! I just thought of something else:
>
> According to the 82371AB datasheet the controller
> itself sets the USBCMD_FGR bit when a global RD is
> detected. So qualifying the wakeup in software won't
> prevent the controller itself from starting the
> wakeup process on a false RD from an OC port. :-(
>
> Hmmmm.... crap
> Is there a way around this or are we back to
> preventing the suspend?
It might not be that bad. What will happen is that the controller will
assert FGR and interrupt the host. The driver will see the global RD, but
will also see that it's present only on OC ports, so the driver will never
leave the SUSPENDED state and will never write a 0 to FGR and EGSM. Hence
the controller will never become active -- the wakeup won't finish.
Of course, it's necessary to worry about what happens if one port is OC,
so the controller is in this permanently-waking-up state, when a device is
plugged into the other port. I think this will re-assert global RD and
generate another interrupt. This time the driver will see that the RD is
for real, so it will complete the wakeup sequence.
Neither of us can easily test that, because it requires one port to be
broken and the other to be working. But if everything else is okay, I
think this will work too.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri May 23 2003 - 22:00:24 EST