Messages in this thread | | | Subject | Re: [PATCH] USB: fix Scheduling while atomic warning when resuming. | From | Benjamin Herrenschmidt <> | Date | Wed, 22 Dec 2004 17:35:58 +0100 |
| |
On Wed, 2004-12-22 at 08:16 -0800, David Brownell wrote: > On Wednesday 22 December 2004 3:59 am, Benjamin Herrenschmidt wrote: > > > > > Similarly, If the USB layer is calling into your driver while you are > > > resuming, something is broken and it ain't your locking. > > > > Actually, the later isn't broken, something may well call into the > > higher level USB drivers while resuming, but indeed, those shouldn't > > send any URB down the stack when the bus is suspended, and the EHCI > > driver should drop incoming URBs as well until fully resumed. > > Well, not "drop" like the network layer might, but report an error; > if the bus is suspended, so are all its devices and drivers. When > a USB device is suspended, all its endpoint queues should be empty. > (And devices can be suspended without the bus being suspended...)
Oh sure, yes, "drop" wasn't the best choice of word, but error is what I meant. Sorry.
> Such checks should be part of usbcore, not just one HCD, but we're > still working towards better interfaces there. It's excessively > painful to write HCDs.
Yes :) > > > I think the lock here is only needed to protect the HCD state > > transitions David, no ? > > State transitions and access to hardware. There are a few other > code paths that can trigger state transitions then, like rmmod. > And Alan's pointed out that we'll be wanting autoresume mechanisms, > so that parent hubs implicitly wake up as needed. > > One thing we don't have right now is a per-HCD spinlock that > usbcore has access to. Periodically I wonder whether such a > lock might help sort some of these issues out. > > > > All we need is make sure that we don't let > > things get queued (or call into EHCI code path that will end up > > touch the HW) while suspended. > > That lock protects all HCD code paths that touch HW, > As well as the state transitions. I don't recall that > any other state transitions require such a long delay, > except maybe initialization (which happens before the > upper levels of the USB stack see the controller). > > - Dave -- Benjamin Herrenschmidt <benh@kernel.crashing.org>
- 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/
| |