Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1765720AbYCFU2h (ORCPT ); Thu, 6 Mar 2008 15:28:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753694AbYCFU22 (ORCPT ); Thu, 6 Mar 2008 15:28:28 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:58743 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751269AbYCFU21 (ORCPT ); Thu, 6 Mar 2008 15:28:27 -0500 Date: Thu, 6 Mar 2008 15:28:26 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: "Rafael J. Wysocki" cc: pm list , Alexey Starikovskiy , Pavel Machek , LKML Subject: Re: [RFC][PATCH] PM: Make PM core handle device registrations concurrent with suspend/hibernation In-Reply-To: <200803062118.32860.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: 1704 Lines: 43 On Thu, 6 Mar 2008, Rafael J. Wysocki wrote: > On Thursday, 6 of March 2008, Alan Stern wrote: > > On Thu, 6 Mar 2008, Rafael J. Wysocki wrote: > > > > > > I thought of one more thing you might want to add: device_pm_add() > > > > doesn't handle the case where dev->parent is NULL. > > > > > > I'm not sure what you mean. > > > > > > If dev->parent is NULL, we get into the "successful" branch where the device is > > > added to dpm_active. Do you think we should add any extra handling of this > > > case? > > > > If a device is registered after dpm_suspend() has returned, the > > device won't be suspended properly before the system goes to sleep. > > > > If the device has a parent then you're okay, because the parent must > > already be suspended and so device_pm_add() will fail. But if the > > device doesn't have a parent then device_pm_add() will succeed, which > > you don't want. > > Well, can it happen in practice? If it can, then what way can it happen? Yes, it can happen in practice when a new module is loaded. In some ways, modules' init routines are like probe methods. Maybe it can happen some other ways too, but I don't know of any. > It seems to me that we're discussing purely academic stuff here. If it turns > out to be of any practical relevance, it will be trivial to add the handling of > it in the future. To be safe, I think we should make system sleep mutually exclusive with module loading. 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/