On 13 May 2003, Paul Fulghum wrote:
> On Tue, 2003-05-13 at 10:26, Alan Stern wrote:
>
> > Putting in a sanity check for the global suspend state will be very easy.
> > But I would like to point out that this "global suspend" does not refer to
> > the entire system, only the USB bus.
>
> That is a problem then, because the delay can still
> occur during normal system operation.
>
> > I'm not sure under what
> > circumstances the bus is placed in global suspend; I think it's just when
> > there are no devices attached (or the last remaining device is detached).
> >
> > However, there have been cases on my own system where turning off the only
> > USB peripheral caused the driver to bounce between suspend_hc() and
> > wakeup_hc() several times without any apparent explanation -- possibly as
> > a result of transient electrical signals on the bus (?). So perhaps
> > moving that delay out of the ISR isn't such a bad idea.
>
> Agreed. If this can happen on functional USB controllers
> when no devices are attached, then it is a serious problem.
Instead of trying to guess when to do it, could the sleep be replaced by
setting a flag bit to indicate that a sleep was needed before using the
hardware? Then the sleep could be done when needed but no noise on the USB
bus wouldn't hurt.
1 - there may be many places, I thought of that but didn't look
since someone will tell me if it's a problem.
2 - if you don't use USB why not just take the driver out?
It would be nice to prevent the problem, of course.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.- 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 : Thu May 15 2003 - 22:00:47 EST