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

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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>