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: NOcean He <hehy1@lenovo.com>
Signed-off-by: NNagananda Chumbalkar <nchumbalkar@lenovo.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NLen Brown <len.brown@intel.com>
Reviewed-by: NMatt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: NChen Yu <yu.c.chen@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit 58a1fbbb ("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: 58a1fbbb (PM / PCI / ACPI: Kick devices that might have been reset by firmware)
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: 4.4+ <stable@vger.kernel.org> # 4.4+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit f06147f9 (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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NLv Zheng <lv.zheng@intel.com>

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+ <stable@vger.kernel.org> # 3.18+
Acked-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NChen Yu <yu.c.chen@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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=84651Reported-and-tested-by: NEthan Schoonover <es@ethanschoonover.com>
Tested-by: NPeter Amidon <psa.pub.0@picnicpark.org>
Tested-by: NYani Ioadnnou <yani.ioannou@gmail.com>
Tested-by: NMister Wardrop <mister.wardrop@gmail.com>
Tested-by: NAnton Anikin <anton@anikin.name>
Tested-by: NKeith McClelland <zismylaptop@gmail.com>
Reviewed-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NChen Yu <yu.c.chen@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The acpi_suspend() function has no callers, so drop it.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>

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: NJan Beulich <jbeulich@suse.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI GPE wakeup from suspend-to-idle is currently based on using
the IRQF_NO_SUSPEND flag for the ACPI SCI, but that is problematic
for a couple of reasons.  First, in principle the ACPI SCI may be
shared and IRQF_NO_SUSPEND does not really work well with shared
interrupts.  Second, it may require the ACPI subsystem to special-case
the handling of device notifications depending on whether or not
they are received during suspend-to-idle in some places which would
lead to fragile code.  Finally, it's better the handle ACPI wakeup
interrupts consistently with wakeup interrupts from other sources.

For this reason, remove the IRQF_NO_SUSPEND flag from the ACPI SCI
and use enable_irq_wake()/disable_irq_wake() with it instead, which
requires two additional platform hooks to be added to struct
platform_freeze_ops.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

NVS region is saved and restored unconditionally for machines without
nvs_nosave quirk during S3. Tested some new machines and the operation
is not necessary. Saving NVS region also affects S2RAM speed. The time of
NVS saving and restoring depends on the size of NVS region and it consumes
7~10ms normally.

This patch is to make machines produced from 2012 to now not saving NVS region
to accelerate S3.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Adds trace events that give finer resolution into suspend/resume. These
events are graphed in the timelines generated by the analyze_suspend.py
script. They represent large areas of time consumed that are typical to
suspend and resume.

The event is triggered by calling the function "trace_suspend_resume"
with three arguments: a string (the name of the event to be displayed
in the timeline), an integer (case specific number, such as the power
state or cpu number), and a boolean (where true is used to denote the start
of the timeline event, and false to denote the end).

The suspend_resume trace event reproduces the data that the machine_suspend
trace event did, so the latter has been removed.
Signed-off-by: NTodd Brandt <todd.e.brandt@intel.com>
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The "freeze" sleep state suffers from the same issue that was
addressed by commit ad07277e (ACPI / PM: Hold acpi_scan_lock over
system PM transitions) for ACPI sleep states, that is, things break
if ->remove() is called for devices whose system resume callbacks
haven't been executed yet.

It also can be addressed in the same way, by holding the ACPI scan
lock over the "freeze" sleep state and PM transitions to and from
that state, but ->begin() and ->end() platform operations for the
"freeze" sleep state are needed for this purpose.

This change has been tested on Acer Aspire S5 with Thunderbolt.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Export the acpi_target_system_state() function to modules so that
modular drivers can use it to check what the target ACPI sleep state
of the system is (that is needed for i915 mostly at this point).
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

If the HW Reduced ACPI mode bit is set in the FADT, ACPICA uses
the optional sleep control and sleep status registers for making
the system enter sleep states (including S5), so it is not possible
to use system sleep states or power it off using ACPI if the HW
Reduced ACPI mode bit is set and those registers are not available.

For this reason, add a new function, acpi_sleep_state_supported(),
checking if the HW Reduced ACPI mode bit is set and whether or not
system sleep states are usable in that case in addition to checking
the return value of acpi_get_sleep_type_data() and make the ACPI
sleep setup routines use that function to check the availability of
system sleep states.

Among other things, this prevents the kernel from attempting to
use ACPI for powering off HW Reduced ACPI systems without the sleep
control and sleep status registers, because ACPI power off doesn't
have a chance to work on them.  That allows alternative power off
mechanisms that may actually work to be used on those systems.  The
affected machines include Dell Venue 8 Pro, Asus T100TA, Haswell
Desktop SDP and Ivy Bridge EP Demo depot.

References: https://bugzilla.kernel.org/show_bug.cgi?id=70931Reported-by: NAdam Williamson <awilliam@redhat.com>
Tested-by: NAubrey Li <aubrey.li@linux.intel.com>
Cc: 3.4+ <stable@vger.kernel.org> # 3.4+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Revert commit 3130497f ("ACPI / sleep: pm_power_off needs more
sanity checks to be installed") that breaks power ACPI power off on a
lot of systems, because it checks wrong registers.

Fixes: 3130497f ("ACPI / sleep: pm_power_off needs more sanity checks to be installed")
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Sleep control and status registers need santity checks as well before
ACPI installs acpi_power_off to pm_power_off hook. The checking code in
acpi_enter_sleep_state() is too late, we should not allow a not-working
pm_power_off function to be hooked up.
Signed-off-by: NAubrey Li <aubrey.li@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Some BIOSes change hardware based on the state of
a laptop's lid. If the lid is closed, the touchpad is
disabled and the checksum changes. Windows 8 no longer
aborts resume if the checksum has changed.
Signed-off-by: NOliver Neukum <oneukum@suse.de>
[rjw: Use pr_crit() for the message and don't break the string]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

acpi_sleep_init() is only called from acpi_bus_init() and the
code logic shows that it doesn't need to check acpi_disabled:

acpi_init();
	if (acpi_disabled) return;
	acpi_bus_init();
		acpi_sleep_init();
			if (acpi_disabled)
				return 0;
Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
[rjw: Subject and changelog]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and
<acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h>
inclusions and remove some inclusions of those files that aren't
necessary.

First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>
should not be included directly from any files that are built for
CONFIG_ACPI unset, because that generally leads to build warnings about
undefined symbols in !CONFIG_ACPI builds.  For CONFIG_ACPI set,
<linux/acpi.h> includes those files and for CONFIG_ACPI unset it
provides stub ACPI symbols to be used in that case.

Second, there are ordering dependencies between those files that always
have to be met.  Namely, it is required that <acpi/acpi_bus.h> be included
prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the
latter depends on are always there.  And <acpi/acpi.h> which provides
basic ACPICA type declarations should always be included prior to any other
ACPI headers in CONFIG_ACPI builds.  That also is taken care of including
<linux/acpi.h> as appropriate.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff)
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff)
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Initialize pwr_btn_status as disabled which (a) makes sure it is
in a proper state to start, and (b) cleans up a compiler warning
about an uninitialized variable.
Signed-off-by: NAl Stone <al.stone@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Bad things happen if ACPI hotplug events are handled during system
PM transitions, especially if devices are removed as a result.
To prevent those bad things from happening, acquire acpi_scan_lock
when a PM transition is started and release it when that transition
is complete or has been aborted.

This fixes resume lockup on my test-bed Acer Aspire S5 that happens
when Thunderbolt devices are disconnected from the machine while
suspended.

Also fixes the analogous problem for Mika Westerberg on an
Intel DZ77RE-75K board.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NToshi Kani <toshi.kani@hp.com>

__initdata should be placed between the variable name and equal
sign for the variable to be placed in the intended section.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Introduce helper function acpi_execute_simple_method() and use it in
a number of places to simplify code.

[rjw: Changelog]
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Which by default will be x86_acpi_suspend_lowlevel.
This registration allows us to register another callback
if there is a need to use another platform specific callback.
Signed-off-by: NLiang Tang <liang.tang@oracle.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: NBen Guthro <benjamin.guthro@citrix.com>
Acked-by: N"H. Peter Anvin" <hpa@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add Sony Vaio VGN-FW21M to the device blacklist in
drivers/acpi/sleep.c.

Fixes suspend/resume on this device (device no longer reboots
instead of resuming).

References: https://bugzilla.kernel.org/show_bug.cgi?id=55001Signed-off-by: NFabio Valentini <fafatheone@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Got this dmesg log on an Acer Aspire 725.

[    0.256351] ACPI: (supports S0ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20130117/hwxface-568)
[    0.256373] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20130117/hwxface-568)
[    0.256391]  S3 S4 S5)

Avoid this interleaving error messages.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch adds a quirk to allow the Sony VGN-FW41E_H to suspend/resume
properly.

References: http://bugs.launchpad.net/bugs/1113547Signed-off-by: NJoseph Salisbury <joseph.salisbury@canonical.com>
Cc: All <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Move some suspend-specific and hibernate-specific code from
acpi_sleep_init() into separate functions to get rid of explicit
#ifdefs in acpi_sleep_init().  Use pr_info() to start and pr_cont()
to continue printing the supported ACPI sleep states line.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI power resources driver is not very useful, because the only
thing it really does is to restore the state of the power resources
that were "on" before system suspend or hibernation, but that may be
achieved in a different way.

Drop the ACPI power resources driver entirely and add
acpi_resume_power_resources() that will walk the list of all
registered power resources during system resume and turn on the ones
that were "on" before the preceding system suspend or hibernation.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The current acpisleep DMI checks only run when CONFIG_SUSPEND is set.
And this may break hibernation on some platforms when CONFIG_SUSPEND
is cleared.

Move acpisleep DMI check into #ifdef CONFIG_ACPI_SLEEP instead.

[rjw: Added acpi_sleep_dmi_check() and rebased on top of earlier
 patches adding entries to acpisleep_dmi_table[].]
References: https://bugzilla.kernel.org/show_bug.cgi?id=45921Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Sony Vaio VPCEB1S1E does not resume correctly without
acpi_sleep=nonvs, so add it to the ACPI sleep blacklist.

References: https://bugzilla.kernel.org/show_bug.cgi?id=48781Reported-by: NSébastien Wilmet <swilmet@gnome.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI specificiation would like us to save NVS at hibernation time,
but makes no mention of saving NVS over S3.  Not all versions of
Windows do this either, and it is clear that not all machines need NVS
saved/restored over S3.  Allow the user to improve their suspend/resume
time by disabling the NVS save/restore at S3 time, but continue to do
the NVS save/restore for S4 as specified.
Signed-off-by: NKristen Carlson Accardi <kristen@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Introduce helper function returning the target sleep state of the
system and use it to move the remaining device power management
functions from sleep.c to device_pm.c.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Two device wakeup management routines in device_pm.c and sleep.c,
acpi_pm_device_run_wake() and acpi_pm_device_sleep_wake(), take a
device pointer argument and use it to obtain the ACPI handle of the
corresponding ACPI namespace node.  That handle is then used to get
the address of the struct acpi_device object corresponding to the
struct device passed as the argument.

Unfortunately, that last operation may be costly, because it involves
taking the global ACPI namespace mutex, so it shouldn't be carried
out too often.  However, the callers of those routines usually call
them in a row with acpi_pm_device_sleep_state() which also takes that
mutex for the same reason, so it would be more efficient if they ran
acpi_bus_get_device() themselves to obtain a pointer to the struct
acpi_device object in question and then passed that pointer to the
appropriate PM routines.

To make that possible, split each of the PM routines mentioned above
in two parts, one taking a struct acpi_device pointer argument and
the other implementing the current interface for compatibility.

Additionally, change acpi_pm_device_run_wake() to actually return
an error code if there is an error while setting up runtime remote
wakeup for the device.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI function for setting up devices to do runtime remote
wakeup is now located in drivers/acpi/sleep.c, but
drivers/acpi/device_pm.c is a more logical place for it, so move it
there.

No functional changes should result from this modification.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI function for choosing device power state is now located
in drivers/acpi/sleep.c, but drivers/acpi/device_pm.c is a more
logical place for it, so move it there.

However, instead of moving the function entirely, move its core only
under a different name and with a different list of arguments, so
that it is more flexible, and leave a wrapper around it in the
original location.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The kerneldoc comments for acpi_pm_device_sleep_state(),
acpi_pm_device_run_wake(), and acpi_pm_device_sleep_wake() are
outdated or otherwise inaccurate and/or don't follow the common
kerneldoc patterns, so fix them.

Additionally, notice that acpi_pm_device_run_wake() should be under
CONFIG_PM_RUNTIME rather than under CONFIG_PM_SLEEP, so fix that too.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>