From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from netrider.rowland.org ([192.131.102.5]:42799 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751671AbcHGPeB (ORCPT ); Sun, 7 Aug 2016 11:34:01 -0400 Date: Sun, 7 Aug 2016 11:33:17 -0400 (EDT) From: Alan Stern To: Lukas Wunner cc: "Rafael J. Wysocki" , , , Andreas Noever Subject: Re: [PATCH v2 11/13] PM / sleep: Allow opt-out from runtime resume after direct-complete In-Reply-To: <20160807095627.GB5679@wunner.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-pci-owner@vger.kernel.org List-ID: On Sun, 7 Aug 2016, Lukas Wunner wrote: > Normally the device hierarchy is traversed bottom-up during suspend > and top-down during resume. However ->prepare and ->complete do it > the other way round. In the case of ->prepare, this is even documented > in Documentation/power/devices.txt but the reason thereof is not. > Could you explain this please? The purpose of ->prepare is to tell drivers that a system sleep is beginning and accordingly they should stop registering new children. This is necessary for the PM core to be able to traverse the entire device tree safely; we want to avoid races where a new child is added below a device concurrently with that device being suspended. (Or if you want to be more precise, races in which a new child is added below a device while the PM core is acquiring the device's lock just prior to invoking its ->suspend callback.) Telling drivers to stop registering new children below a device has to be done top-down, because if it were done bottom-up then it would be subject to the same race described above. Doing it top-down avoids problems; if a device registers new children while the PM core is acquiring its lock prior to invoking ->prepare, it doesn't matter. The new children will be handled later, right along with the existing ones. Alan Stern From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Stern Subject: Re: [PATCH v2 11/13] PM / sleep: Allow opt-out from runtime resume after direct-complete Date: Sun, 7 Aug 2016 11:33:17 -0400 (EDT) Message-ID: References: <20160807095627.GB5679@wunner.de> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: Received: from netrider.rowland.org ([192.131.102.5]:53095 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751633AbcHGPeB (ORCPT ); Sun, 7 Aug 2016 11:34:01 -0400 In-Reply-To: <20160807095627.GB5679@wunner.de> Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Lukas Wunner Cc: "Rafael J. Wysocki" , linux-pci@vger.kernel.org, linux-pm@vger.kernel.org, Andreas Noever On Sun, 7 Aug 2016, Lukas Wunner wrote: > Normally the device hierarchy is traversed bottom-up during suspend > and top-down during resume. However ->prepare and ->complete do it > the other way round. In the case of ->prepare, this is even documented > in Documentation/power/devices.txt but the reason thereof is not. > Could you explain this please? The purpose of ->prepare is to tell drivers that a system sleep is beginning and accordingly they should stop registering new children. This is necessary for the PM core to be able to traverse the entire device tree safely; we want to avoid races where a new child is added below a device concurrently with that device being suspended. (Or if you want to be more precise, races in which a new child is added below a device while the PM core is acquiring the device's lock just prior to invoking its ->suspend callback.) Telling drivers to stop registering new children below a device has to be done top-down, because if it were done bottom-up then it would be subject to the same race described above. Doing it top-down avoids problems; if a device registers new children while the PM core is acquiring its lock prior to invoking ->prepare, it doesn't matter. The new children will be handled later, right along with the existing ones. Alan Stern