On Wed, 27 Feb 2008, Rafael J. Wysocki wrote: > > All right, we can set it to RESUME_RUNNING before calling the resume > > method and then set it to 0 afterwards. The point is that the value > > shouldn't remain SUSPEND_DONE while resume runs, because it should be > > legal for resume to register new children. > > I'm not sure. The core moves the device to dpm_active only after ->resume() > has run. Actually the move is done before the method is called. So this isn't a problem. ... > > > > The one tricky thing to watch out for is when a suspend or resume > > > > method wants to unregister the device being suspended or resumed. > > > > > > That can't happen, because dev->sem is taken by suspend_device() and > > > device_del() would lock up attempting to acquire it once again. > > > > We'll have to fix device_del() to prevent that from happening. Your > > in_sleep_context() approach should work. > > I'm not sure if we need to do it. It's always been like this, so the current > drivers' ->suspend() and ->resume() don't unregister the device they're called > for. I don't see any advantage from doing that for future drivers. All right, if it doesn't happen now then we don't need to allow for it. That makes life a little simpler. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm