From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751515AbdKVB3V (ORCPT ); Tue, 21 Nov 2017 20:29:21 -0500 Received: from cloudserver094114.home.net.pl ([79.96.170.134]:60606 "EHLO cloudserver094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751379AbdKVB3S (ORCPT ); Tue, 21 Nov 2017 20:29:18 -0500 From: "Rafael J. Wysocki" To: "Rafael J. Wysocki" Cc: Ulf Hansson , Linux PM , Bjorn Helgaas , Alan Stern , Greg Kroah-Hartman , LKML , Linux ACPI , Linux PCI , Linux Documentation , Mika Westerberg , Andy Shevchenko , Kevin Hilman Subject: Re: [PATCH v4 5/6] PM / core: Direct handling of DPM_FLAG_LEAVE_SUSPENDED Date: Wed, 22 Nov 2017 02:28:58 +0100 Message-ID: <19138154.CxoQn1onCO@aspire.rjw.lan> In-Reply-To: <4400947.0Tgl7arJ6a@aspire.rjw.lan> References: <3806130.B2KCK0tvef@aspire.rjw.lan> <4400947.0Tgl7arJ6a@aspire.rjw.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, November 22, 2017 2:10:51 AM CET Rafael J. Wysocki wrote: > On Monday, November 20, 2017 2:42:26 PM CET Ulf Hansson wrote: > > On 18 November 2017 at 15:41, Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki > > > > > > Make the PM core handle DPM_FLAG_LEAVE_SUSPENDED directly for > > > devices whose "noirq", "late" and "early" driver callbacks are > > > invoked directly by it. > > > > This indicates that your target for this particular change isn't > > ACPI/PCI, but instead this aims to be a more generic solution to be > > able to optimize the resume path for devices. > > > > Assuming, this is the case, I don't think this is good enough as I > > pointed out [1] earlier. Simply because it isn't as flexible as is > > required - to really be able cover generic cases. > > I'll go back to that message, but nothing so far has been flexible enough to > cover everything you can imagine. > > The case this and the next patch cover really is to allow drivers that can be > used with or without a PM domain to avoid doing any "are we suspended?" type > of checks in their callbacks. Actually, the [6/6] is more important from that > standpoint, but this one also may play the role because of the dependencies > between devices involved in the handling of LEAVE_SUSPENDED (eg. say a PCI > parent has a child platform or I2C or similar devices without a PM domain > and what happens to the child affects the parent). > > > > > > > Namely, make it skip all of the system-wide resume callbacks for > > > such devices with DPM_FLAG_LEAVE_SUSPENDED set if they are in > > > runtime suspend during the "noirq" phase of system-wide suspend > > > (or analogous) transitions or the system transition under way is > > > a proper suspend (rather than anything related to hibernation) and > > > the device's wakeup settings are compatible with runtime PM (that > > > is, the device cannot generate wakeup signals at all or it is > > > allowed to wake up the system from sleep). > > > > As I pointed out by submitting another patch [2], device_may_wakeup() > > doesn't really tell whether the wakeup is configured as "in-band" or > > "out-of-band". That knowledge is known by the driver and the subsystem > > layer - and for that reason I don't think the PM core shall base > > generic decisions like this on it. > > The "or it is allowed to wake up the system from sleep" case may be overly > optimistic, but the remaining two (runtime-suspended devices and devices > that can't generate wakeup signals at all) are quite straightforward to me. BTW, I'm not sure if the device_may_wakeup() check is really insufficient in this particular case. Say the device was not in runtime suspend before, but device_may_wakeup() returns "true" for it and the system is resuming from suspend. The device's state should be suitable to wake up the system in any case, so the "in-band" vs "out-of-band" difference has had to be taken care of already during system suspend. Thanks, Rafael