Messages in this thread | | | From | David Brownell <> | Subject | Re: [PATCH] USB: fix Scheduling while atomic warning when resuming. | Date | Wed, 22 Dec 2004 08:16:42 -0800 |
| |
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 - 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/
| |