lkml.org 
[lkml]   [2004]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] USB: fix Scheduling while atomic warning when resuming.
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.055 / U:1.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site