On Tue, 14 Dec 2010, Rafael J. Wysocki wrote: > On Monday, December 13, 2010, Alan Stern wrote: > > On Mon, 13 Dec 2010, Rafael J. Wysocki wrote: > > > > > From: Rafael J. Wysocki <rjw@xxxxxxx> > > > > > > The registration of a new parentless device during system suspend > > > will not lead to any complications affecting the PM core (the device > > > will be effectively seen after the subsequent resume has completed), > > > so remove the code used for detection of such events. > > > > Actually the tests you're changing were never as strong as they should > > have been. Drivers are supposed to avoid registering new children > > beneath a device as soon as the device has gone through the "prepare" > > stage, not just after the device is suspended. Should there be a > > "prepared" bitflag to help implement this stronger test? > > The in_suspend flag introduced by [3/4] works like this, actually. Not entirely, because it doesn't get set until the device has gone through the "suspend" stage. > > In principle the same idea applies to parentless devices, since they > > can be considered children of the "system device" (a fictitious node at > > the root of the device tree). The "system" goes into the prepared > > state before all the real devices; that's what the transition_started > > variable was all about. It's nothing more than the "prepared" bitflag > > for the "system device". > > It has never worked like this, because it was cleared as early as at the > _noirq() stage. That was part of our lenient approach, allowing devices to be registered during system resume earlier than the documentation says they should be. > Hmm. It looks like I should modify [3/4] to clear the in_suspend flag earlier > to follow the current behavior (if a device is DPM_RESUMING, registration of > new children doesn't trigger the warning). You could clear in_suspend at the start of device_resume. In the end, it's a question of what are we trying to accomplish. The warnings catch the most egregious violations of the documented requirements. Is the purpose to let people know about the violations, or is it to warn about actions that appear genuinely dangerous? Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
