Re: [PATCH] USB: fix Scheduling while atomic warning when resuming.

From: Benjamin Herrenschmidt
Date: Wed Dec 22 2004 - 11:39:30 EST

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@xxxxxxxxxxxxxxxxxxx>

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at