kernel/git/stable/linux.git/drivers/acpi/sleep.c, branch linux-4.4.y

ACPI / PM: save NVS memory for ASUS 1025C laptop

2018-08-22T05:48:37+00:00

commit 231f9415001138a000cd0f881c46654b7ea3f8c5 upstream. Every time I tried to upgrade my laptop from 3.10.x to 4.x I faced an issue by which the fan would run at full speed upon resume. Bisecting it showed me the issue was introduced in 3.17 by commit 821d6f0359b0 (ACPI / sleep: Do not save NVS for new machines to accelerate S3). This code only affects machines built starting as of 2012, but this Asus 1025C laptop was made in 2012 and apparently needs the NVS data to be saved, otherwise the CPU's thermal state is not properly reported on resume and the fan runs at full speed upon resume. Here's a very simple way to check if such a machine is affected : # cat /sys/class/thermal/thermal_zone0/temp 55000 ( now suspend, wait one second and resume ) # cat /sys/class/thermal/thermal_zone0/temp 0 (and after ~15 seconds the fan starts to spin) Let's apply the same quirk as commit cbc00c13 (ACPI: save NVS memory for Lenovo G50-45) and reuse the function it provides. Note that this commit was already backported to 4.9.x but not 4.4.x. Cc: 3.17+ # 3.17+: requires cbc00c13 Signed-off-by: Willy Tarreau Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI: save NVS memory for Lenovo G50-45

2018-08-22T05:48:37+00:00

commit cbc00c1310d34139a63946482b40a6b261a03fb9 upstream. In commit 821d6f0359b0 (ACPI / sleep: Do not save NVS for new machines to accelerate S3), to optimize S3 suspend/resume speed, code is introduced to ignore NVS memory saving during S3 for all the platforms later than 2012. But, Lenovo G50-45, a platform released in 2015, still needs NVS memory saving during S3. A quirk is introduced for this platform. Link: https://bugzilla.kernel.org/show_bug.cgi?id=189431 Tested-by: Przemek Signed-off-by: Zhang Rui [ rjw: Drop unnecessary code ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI / PM: Runtime resume devices when waking from hibernate

2016-04-12T16:09:03+00:00

commit fbda4b38fa3995aa0777fe9cbbdcb223c6292083 upstream. 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 Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

Merge branch 'pm-sleep'

2015-11-01T23:52:19+00:00

* pm-sleep: PM / hibernate: fix a comment typo input: i8042: Avoid resetting controller on system suspend/resume PM / PCI / ACPI: Kick devices that might have been reset by firmware PM / sleep: Add flags to indicate platform firmware involvement PM / sleep: Drop pm_request_idle() from pm_generic_complete() PCI / PM: Avoid resuming more devices during system suspend PM / wakeup: wakeup_source_create: use kstrdup_const PM / sleep: Report interrupt that caused system wakeup

ACPI / PM: Fix incorrect wakeup IRQ setting during suspend-to-idle

2015-10-26T03:39:26+00:00

For an ACPI compatible system, the SCI (ACPI System Control Interrupt) is used to wake the system up from suspend-to-idle. Once the CPU is woken up by the SCI, the interrupt handler will first check if the current IRQ has been configured for system wakeup, so irq_pm_check_wakeup() is invoked to validate the IRQ number. However, during suspend-to-idle, enable_irq_wake() is called for acpi_gbl_FADT.sci_interrupt, although the IRQ number that the SCI handler has been installed for should be passed to it instead. Thus, if acpi_gbl_FADT.sci_interrupt happens to be different from that number, ACPI interrupts will not be able to wake up the system from sleep. Fix this problem by passing the IRQ number returned by acpi_gsi_to_irq() to enable_irq_wake() instead of acpi_gbl_FADT.sci_interrupt. Cc: 3.18+ # 3.18+ Acked-by: Lv Zheng Signed-off-by: Chen Yu Signed-off-by: Rafael J. Wysocki

PM / sleep: Add flags to indicate platform firmware involvement

2015-10-14T00:17:33+00:00

There are quite a few cases in which device drivers, bus types or even the PM core itself may benefit from knowing whether or not the platform firmware will be involved in the upcoming system power transition (during system suspend) or whether or not it was involved in it (during system resume). For this reason, introduce global system suspend flags that can be used by the platform code to expose that information for the benefit of the other parts of the kernel and make the ACPI core set them as appropriate. Users of the new flags will be added later. Signed-off-by: Rafael J. Wysocki

ACPI / PM: Enable all wakeup GPEs in suspend-to-idle

2015-03-29T23:52:02+00:00

Currently, in suspend-to-idle, wakeup GPE for PCI devices are handled properly because acpi_pci_sleep_wake() invokes acpi_enable_gpe() to enable the wakeup GPE directly. But for the other wakeup-capable devices in ACPI bus, acpi_enable_wakeup_devices() should be invoked to update enable_for_wake mask in gpe_register_info structure, thus acpi_enable_all_wakeup_gpes() can enable the wakeup GPE referred in _PRW methods. And acpi_disable_wakeup_devices() will be called before disable_irq_wake() in acpi_freeze_restore() to restore the mask. This patch fixes a power button wakeup problem on Surface Pro 3, on which platform power button uses EC to deliver event (EC GPE is referred in _PRW). Note: enabling EC GPE during freeze state may bring some risks because EC events are expected to fire more frequently than others. Thus it may bring the system out of freeze state unnecessarily. (We already have comments about this in bugzilla) Link: https://bugzilla.kernel.org/show_bug.cgi?id=84651 Reported-and-tested-by: Ethan Schoonover Tested-by: Peter Amidon Tested-by: Yani Ioadnnou Tested-by: Mister Wardrop Tested-by: Anton Anikin Tested-by: Keith McClelland Reviewed-by: Zhang Rui Signed-off-by: Chen Yu Signed-off-by: Rafael J. Wysocki

ACPI / sleep: Drop acpi_suspend() which is not used

2015-03-18T11:53:21+00:00

The acpi_suspend() function has no callers, so drop it. Signed-off-by: Rafael J. Wysocki Acked-by: Lorenzo Pieralisi Reviewed-by: Hanjun Guo

ACPI / sleep: mark acpi_sleep_dmi_check() __init

2015-01-23T21:10:16+00:00

This makes a difference if the compiler decides not to inline the function, as then the function's reference to acpisleep_dmi_table[] yields a section mismatch warning. Signed-off-by: Jan Beulich Signed-off-by: Rafael J. Wysocki

ACPI / sleep: Drain outstanding events after disabling multiple GPEs

2014-12-01T22:51:13+00:00

After multiple GPEs have been disabled at the low level in one go, like when acpi_disable_all_gpes() is called, we should always drain all of the outstanding events from them, or interesting races become possible. For this reason, call acpi_os_wait_events_complete() after acpi_enable_all_wakeup_gpes() and acpi_disable_all_gpes() in acpi_freeze_prepare() and acpi_power_off_prepare(), respectively. Signed-off-by: Rafael J. Wysocki