[PATCH 0/2] Hibernate runtime-resume fixes

[PATCH 0/2] Hibernate runtime-resume fixes

[Lukas Wunner]

I stumbled across these two issues while implementing runtime pm for
Thunderbolt. Unfortunately hibernate is not working on my machine
(no swap partition) so I could not test the patches beyond verifying
that they compile. I merely had the impression that this is wrong
when reading the code. Somebody please double-check if the patches
are legitimate. If they are not then I apologize for the noise.

Best regards,

Lukas


Lukas Wunner (2):
  PM / sleep: Clear pm_suspend_global_flags upon hibernate
  ACPI / PM: Runtime resume devices when waking from hibernate

 drivers/acpi/sleep.c     | 1 +
 kernel/power/hibernate.c | 1 +
 2 files changed, 2 insertions(+)

-- 
1.8.5.2 (Apple Git-48)

[PATCH 1/2] PM / sleep: Clear pm_suspend_global_flags upon hibernate

[Lukas Wunner]

When suspending to RAM, waking up and later suspending to disk,
we gratuitously runtime resume devices after the thaw phase.
This does not occur if we always suspend to RAM or always to disk.

pm_complete_with_resume_check(), which gets called from
pci_pm_complete() among others, schedules a runtime resume
if PM_SUSPEND_FLAG_FW_RESUME is set. The flag is set during
a suspend-to-RAM cycle. It is cleared at the beginning of
the suspend-to-RAM cycle but not afterwards and it is not
cleared during a suspend-to-disk cycle at all. Fix it.

Fixes: ef25ba047601 ("PM / sleep: Add flags to indicate platform
    firmware involvement")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
---
 kernel/power/hibernate.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index aa0f26b..fca9254 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -339,6 +339,7 @@ int hibernation_snapshot(int platform_mode)
 	pm_message_t msg;
 	int error;
 
+	pm_suspend_clear_flags();
 	error = platform_begin(platform_mode);
 	if (error)
 		goto Close;
-- 
1.8.5.2 (Apple Git-48)

[PATCH 2/2] ACPI / PM: Runtime resume devices when waking from hibernate

[Lukas Wunner]

Commit 58a1fbbb2ee8 ("PM / PCI / ACPI: Kick devices that might have been
reset by firmware") added a runtime resume for devices that were runtime
suspended when the system entered suspend-to-RAM.

Briefly, the motivation was to ensure that devices did not remain in a
reset-power-on state after resume, potentially preventing deep SoC-wide
low-power states from being entered on idle.

Currently we're not doing the same when leaving suspend-to-disk and this
asymmetry is a problem if drivers rely on the automatic resume triggered
by pm_complete_with_resume_check(). Fix it.

Fixes: 58a1fbbb2ee8 ("PM / PCI / ACPI: Kick devices that might have been
    reset by firmware")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
---
 drivers/acpi/sleep.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index fbfcce3..2a8b596 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -748,6 +748,7 @@ static int acpi_hibernation_enter(void)
 
 static void acpi_hibernation_leave(void)
 {
+	pm_set_resume_via_firmware();
 	/*
 	 * If ACPI is not enabled by the BIOS and the boot kernel, we need to
 	 * enable it here.
-- 
1.8.5.2 (Apple Git-48)

Re: [PATCH 0/2] Hibernate runtime-resume fixes

[Rafael J. Wysocki]

On Wednesday, March 23, 2016 12:11:20 AM Lukas Wunner wrote:
> I stumbled across these two issues while implementing runtime pm for
> Thunderbolt. Unfortunately hibernate is not working on my machine
> (no swap partition) so I could not test the patches beyond verifying
> that they compile. I merely had the impression that this is wrong
> when reading the code. Somebody please double-check if the patches
> are legitimate. If they are not then I apologize for the noise.

Both are legitimate in my view, so I've applied them and marked them for
"stable".

The subject of the second one is slightly not to the point (as this is
more about telling drivers that platform firmware has been involved
in the resume operation, which may or may not be related to runtime
resuming them etc), but then I can't invent a better one anyway.

Thanks,
Rafael