Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755011Ab0LMEJV (ORCPT ); Sun, 12 Dec 2010 23:09:21 -0500 Received: from netrider.rowland.org ([192.131.102.5]:57982 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753235Ab0LMEJU (ORCPT ); Sun, 12 Dec 2010 23:09:20 -0500 Date: Sun, 12 Dec 2010 23:09:13 -0500 (EST) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: "Rafael J. Wysocki" cc: LKML , Linus Torvalds , Linux-pm mailing list Subject: Re: [RFC][PATCH 4/4] PM: Permit registrarion of parentless devices during system suspend In-Reply-To: <201012130133.52072.rjw@sisk.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1691 Lines: 36 On Mon, 13 Dec 2010, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > 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? 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". I guess it's okay to be lenient and not check for this. But should we then change the documentation to match? (Note that the warning won't be triggered if a new child is registered _as_ the parent is suspending. Not to mention the possibilities for mischief when devices are suspended asynchronously. But as you say, these complications don't affect the PM core.) Alan Stern -- 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/