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

[David Brownell <david-b@pacbell.net>]

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...)

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.


> 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