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

Revert "ACPI: Execute _PTS before system reboot"

2016-12-15T16:50:36Z

commit 9713adc2a1a5488f4889c657a0c0ce0c16056d3c upstream. Revert commit 2c85025c75df (ACPI: Execute _PTS before system reboot) as it is reported to cause poweroff and reboot to hang on Dell Latitude E7250. Link: https://bugzilla.kernel.org/show_bug.cgi?id=187061 Reported-by: Gianpaolo Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI: Execute _PTS before system reboot

2016-06-29T21:44:02Z

The _PTS control method is defined in the section 7.4.1 of acpi 6.0 spec. The _PTS control method is executed by the OS during the sleep transition process for S1, S2, S3, S4, and for orderly S5 shutdown. The _PTS control method provides the BIOS a mechanism for performing some housekeeping, such as writing the sleep type value to the embedded controller, before entering the system sleeping state. Note that some Lenovo Server BIOS use this mechanism to detect reboot event and prompt user by popped dialog box. According to section 7.5 of acpi 6.0 spec, _PTS should run after _TTS. Add a _PTS evaulation to the existing _TTS reboot notifier and change the notifier name to reflect the fact that it's not for _TTS only any more. Signed-off-by: Ocean He Signed-off-by: Nagananda Chumbalkar Signed-off-by: Rafael J. Wysocki

ACPI / PM: Introduce efi poweroff for HW-full platforms without _S5

2016-04-09T00:11:43Z

The problem is Linux registers pm_power_off = efi_power_off only if we are in hardware reduced mode. Actually, what we also want is to do this when ACPI S5 is simply not supported on non-legacy platforms. Since some future Intel platforms are HW-full mode where the DSDT fails to supply an _S5 object(without SLP_TYP), we should let such kind of platform to leverage efi runtime service to poweroff. This patch uses efi power off as first choice when S5 is unavailable, even if there is a customized poweroff(driver provided, eg). Meanwhile, the legacy platforms will not be affected because there is no path for them to overwrite the pm_power_off to efi power off. Suggested-by: Len Brown Reviewed-by: Matt Fleming Signed-off-by: Chen Yu Signed-off-by: Rafael J. Wysocki

Merge branches 'pm-avs', 'pm-clk', 'pm-devfreq' and 'pm-sleep'

2016-03-24T23:58:18Z

* pm-avs: PM / AVS: rockchip-io: add io selectors and supplies for rk3399 * pm-clk: PM / clk: Add support for obtaining clocks from device-tree * pm-devfreq: PM / devfreq: Spelling s/frequnecy/frequency/ * pm-sleep: ACPI / PM: Runtime resume devices when waking from hibernate PM / sleep: Clear pm_suspend_global_flags upon hibernate

ACPI / PM: Runtime resume devices when waking from hibernate

2016-03-23T01:43:11Z

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 Cc: 4.4+ # 4.4+ Signed-off-by: Rafael J. Wysocki

ACPI / sleep: move acpi_processor_sleep to sleep.c

2016-02-21T23:53:56Z

acpi_processor_sleep is neither related nor used by CPUIdle framework. It's used in system suspend/resume path as a syscore operation. It makes more sense to move it to acpi/sleep.c where all the S-state transition (a.k.a. Linux system suspend/hiberate) related code are present. Also make it depend on CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT so that it's not compiled on architecture like ARM64 where S-states are not yet defined in ACPI. Signed-off-by: Sudeep Holla Signed-off-by: Rafael J. Wysocki

ACPICA: Drop Linux-specific waking vector functions

2016-01-04T21:05:20Z

Commit f06147f9fbf1 (ACPICA: Hardware: Enable firmware waking vector for both 32-bit and 64-bit FACS) added three functions that aren't present in upstream ACPICA, acpi_hw_set_firmware_waking_vectors(), acpi_set_firmware_waking_vectors() and acpi_set_firmware_waking_vector64(), to allow Linux to use the previously existing API for setting the platform firmware waking vector. However, that wasn't necessary, since the ACPI sleep support code in Linux can be modified to use the upstream ACPICA's API easily and the additional functions may be dropped which reduces the code size and puts the kernel's ACPICA code more in line with the upstream. Make the changes as per the above. While at it, make the relevant function desctiption comments reflect the upstream ACPICA's ones. Signed-off-by: Rafael J. Wysocki Acked-by: Lv Zheng

Merge branch 'pm-sleep'

2015-11-01T23:52:19Z

* 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:26Z

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:33Z

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