On Tue, 8 Mar 2005, Paul Mackerras wrote:
> Alan Stern writes:
>
> > My thought exactly! Would it suffice to have the PM suspend and resume
> > routines get a read lock on the bus subsystem's rwsem?
>
> Sounds to me like a recipe for deadlock, unless we are very careful.
> It is quite feasible for the resume routine to discover that a bus has
> been added or removed.
I'm glad you joined in, since you've spent a good deal of time thinking
about these problems. They're quite tricky, especially for USB where
several logical devices ("interfaces") are enclosed in a single physical
device.
Adding or removing a bus is like adding or removing a device, in that they
both will generate hotplug events, right? So they inevitably involve
userspace. But during a suspend or resume there may not be a userspace
available -- all processes may be stuck in the refrigerator.
Is it feasible to arrange for delayed handling of things like this? Set
up a workqueue item that can run when the system is once again fully
functional?
Alternatively (and this will most likely end up being necessary in any
case), the driver-model core should add some entry points in which the
necessary locks are already owned by the caller. Just what those locks
are and when they need to be held is somewhat cloudy at the moment, but
however it turns out we'll undoubtedly want to be able to do the
equivalent of calling device_add() while holding the (soon-to-be-defunct)
bus rwsem.
Alan Stern
