[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0804021658170.2107-100000@iolanthe.rowland.org>
Date: Wed, 2 Apr 2008 17:08:59 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: David Brownell <david-b@...bell.net>
cc: Mark Lord <lkml@....ca>, <pavel@...e.cz>, <oliver@...kum.org>,
<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<jikos@...e.cz>, <gregkh@...e.de>, <akpm@...ux-foundation.org>
Subject: Re: [PATCH] usb ehci_iaa_watchdog fix
On Wed, 2 Apr 2008, David Brownell wrote:
> > It fixes the cause rather than the symptom.
>
> I'm not sure I'd agree with that.
Really? The logic seemed clear enough to me.
1. Evidently the ehci_iaa_watchdog routine was getting called at a
time when the host controller wasn't running -- which had to
have been after it was suspended.
2. But ehci_bus_suspend() calls end_unlink_async(), which turns
off the IAA watchdog timer.
3. Hence the timer must have been restarted later on while
ehci_bus_suspend() was still running. The call to ehci_work()
appeared to be the only place that could have happened.
4. Thus moving the end_unlink_async() call to after ehci_work()
(or just to be doubly safe, after ehci_halt() and the change
to HC_STATE_SUSPENDED) should take care of all pending QH
unlinks and leave none of them unfinished.
Strictly speaking, it would be best to move the del_timer_sync() calls
to after ehci_lock is released. But it doesn't really matter if the
timer routines get invoked after the controller is suspended.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists