mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Linux PM list <linux-pm@vger.kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: [RFC][PATCH 2/2] PM / sleep: Kick devices that might have been reset by firmware
Date: Wed, 30 Sep 2015 02:53:22 +0200	[thread overview]
Message-ID: <5732365.XVsXxYIbHS@vostro.rjw.lan> (raw)
In-Reply-To: <10641052.oOBhM6BU9G@vostro.rjw.lan>

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

If the platform firmware was involved in the system resume that's
being completed, there is a concern that some devices might have
been reset by it and if those devices had the power.direct_complete
flag set during the preceding suspend transition, they may stay
in a reset-power-on state indefinitely (until they are runtime-resumed
and then suspended again).  That may not be a big deal from the
individual device's perspective, but if the system is an SoC, it may
be prevented from entering deep SoC-wide low-power states on idle
because of that.

To prevent that from happening, force a runtime resume for devices
with power.direct_complete set if the platform firmware was involved
in the resume transition currently in progress.

Something similar was done by the ACPI PM domain, but regardless of
the platform firmware involvement, and the new mechanism should be
sufficient to replace that code, so drop it.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/acpi/device_pm.c  |    7 -------
 drivers/base/power/main.c |    7 +++++++
 2 files changed, 7 insertions(+), 7 deletions(-)

Index: linux-pm/drivers/acpi/device_pm.c
===================================================================
--- linux-pm.orig/drivers/acpi/device_pm.c
+++ linux-pm/drivers/acpi/device_pm.c
@@ -969,13 +969,6 @@ EXPORT_SYMBOL_GPL(acpi_subsys_prepare);
 void acpi_subsys_complete(struct device *dev)
 {
 	pm_generic_complete(dev);
-	/*
-	 * If the device had been runtime-suspended before the system went into
-	 * the sleep state it is going out of and it has never been resumed till
-	 * now, resume it in case the firmware powered it up.
-	 */
-	if (dev->power.direct_complete)
-		pm_request_resume(dev);
 }
 EXPORT_SYMBOL_GPL(acpi_subsys_complete);
 
Index: linux-pm/drivers/base/power/main.c
===================================================================
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -928,6 +928,13 @@ static void device_complete(struct devic
 	device_unlock(dev);
 
 	pm_runtime_put(dev);
+	/*
+	 * If the device had been runtime-suspended before the system went into
+	 * the sleep state it is going out of and it has never been resumed till
+	 * now, resume it in case the firmware powered it up.
+	 */
+	if (dev->power.direct_complete && pm_resume_via_firmware())
+		pm_request_resume(dev);
 }
 
 /**


  parent reply	other threads:[~2015-09-30  0:26 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-30  0:46 [RFC][PATCH 0/2] PM / sleep: Make it possible to check if suspend/resume goes via firmware Rafael J. Wysocki
2015-09-30  0:52 ` [RFC][PATCH 1/2] PM / sleep: Add flags to indicate platform firmware involvement Rafael J. Wysocki
2015-09-30  0:53 ` Rafael J. Wysocki [this message]
2015-09-30  0:36   ` [RFC][PATCH 2/2] PM / sleep: Kick devices that might have been reset by firmware kbuild test robot
2015-09-30 14:46   ` Alan Stern
2015-09-30 21:51     ` Rafael J. Wysocki
2015-10-01 14:47       ` Alan Stern
2015-10-01 22:13         ` Rafael J. Wysocki
2015-10-02  1:50 ` [RFC][PATCH v2 0/2] PM / sleep: Make it possible to check if suspend/resume goes via firmware Rafael J. Wysocki
2015-10-02  1:52   ` [RFC][PATCH v2 1/2] PM / sleep: Add flags to indicate platform firmware involvement Rafael J. Wysocki
2015-10-02  1:54   ` [RFC][PATCH v2 2/2] PM / PCI / ACPI: Kick devices that might have been reset by firmware Rafael J. Wysocki
2015-10-06 22:48   ` [PATCH v3 0/3] PM / sleep: Make it possible to check if suspend/resume goes via firmware Rafael J. Wysocki
2015-10-06 22:49     ` [PATCH v3 1/3] PM / sleep: Add flags to indicate platform firmware involvement Rafael J. Wysocki
2015-10-06 22:50     ` [PATCH v3 2/3] PM / PCI / ACPI: Kick devices that might have been reset by firmware Rafael J. Wysocki
2015-10-06 22:53     ` [RFC][PATCH v3 3/3] input: i8042: Avoid resetting controller on system suspend/resume Rafael J. Wysocki
2015-10-06 22:34       ` Dmitry Torokhov
2015-10-06 23:08         ` Rafael J. Wysocki
2015-10-06 22:43           ` Dmitry Torokhov
2015-10-06 23:31             ` Rafael J. Wysocki
2015-10-06 23:11               ` kbuild test robot
2015-10-06 23:26               ` Dmitry Torokhov
2015-10-06 23:44                 ` Rafael J. Wysocki
2015-10-07  1:03       ` [Update][PATCH " Rafael J. Wysocki
2015-10-12 20:17         ` Rafael J. Wysocki
2015-10-12 20:11           ` Dmitry Torokhov
2015-10-12 20:41             ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5732365.XVsXxYIbHS@vostro.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=daniel.vetter@intel.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome