From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [PATCH v3 1/6] PM / core: Add LEAVE_SUSPENDED driver flag Date: Fri, 17 Nov 2017 13:45:16 +0100 Message-ID: References: <3806130.B2KCK0tvef@aspire.rjw.lan> <5556673.MXo6XDN1f4@aspire.rjw.lan> <2654404.6YT5rmSnae@aspire.rjw.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <2654404.6YT5rmSnae@aspire.rjw.lan> Sender: linux-doc-owner@vger.kernel.org To: Ulf Hansson Cc: Linux PM , Bjorn Helgaas , Alan Stern , Greg Kroah-Hartman , LKML , Linux ACPI , Linux PCI , Linux Documentation , Mika Westerberg , Andy Shevchenko , Kevin Hilman , "Rafael J. Wysocki" List-Id: linux-acpi@vger.kernel.org On Fri, Nov 17, 2017 at 12:07 AM, Rafael J. Wysocki wrote: > On Thursday, November 16, 2017 4:10:16 PM CET Ulf Hansson wrote: >> On 12 November 2017 at 01:37, Rafael J. Wysocki wrote: >> > From: Rafael J. Wysocki >> > >> > Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to >> > instruct the PM core and middle-layer (bus type, PM domain, etc.) >> > code that it is desirable to leave the device in runtime suspend >> > after system-wide transitions to the working state (for example, >> > the device may be slow to resume and it may be better to avoid >> > resuming it right away). >> > >> > Generally, the middle-layer code involved in the handling of the >> > device is expected to indicate to the PM core whether or not the >> > device may be left in suspend with the help of the device's >> > power.may_skip_resume status bit. That has to happen in the "noirq" >> > phase of the preceding system suspend (or analogous) transition. >> > The middle layer is then responsible for handling the device as >> > appropriate in its "noirq" resume callback which is executed >> > regardless of whether or not the device may be left suspended, but >> > the other resume callbacks (except for ->complete) will be skipped >> > automatically by the core if the device really can be left in >> > suspend. >> > >> > The additional power.must_resume status bit introduced for the >> > implementation of this mechanisn is used internally by the PM core >> > to track the requirement to resume the device (which may depend on >> > its children etc). >> > >> > Signed-off-by: Rafael J. Wysocki >> > Acked-by: Greg Kroah-Hartman >> > --- >> > >> > v2 -> v3: Take dev->power.usage_count when updating power.must_resume in >> > __device_suspend_noirq(). >> > >> > --- [...] >> > + } else { >> > + dev->power.must_resume = true; >> > + } >> > + >> > + if (dev->power.must_resume) >> > + dpm_superior_set_must_resume(dev); >> > >> > Complete: >> > complete_all(&dev->power.completion); >> > @@ -1487,6 +1539,9 @@ static int __device_suspend(struct devic >> > dev->power.direct_complete = false; >> > } >> > >> > + dev->power.may_skip_resume = false; >> > + dev->power.must_resume = false; >> > + >> >> First, these assignment could be bypassed if the direct_complete path >> is used. Perhaps it's more robust to reset these flags already in >> device_prepare(). > > In the direct-complete case may_skip_resume doesn't matter. > > must_resume should be set to "false", however, so that parents of > direct-complete devices may be left in suspend (in case they don't > fall under direct-complete themselves), so good catch. Actually, not really. must_resume for parents/suppliers is not updated if the device has direct_complete set and the device's own must_resume doesn't matter then. So this part is good as is AFAICS. Thanks, Rafael