Apparently, Sony Vaio VGN-SR26GN_P 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=16396#c91Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

DMI workaround for A8N-SLI Premium and A8N-SLI DELUXE
to enable the s3 suspend old ordering.
http://bugzilla.kernel.org/show_bug.cgi?id=9528Tested-by: NHeiko Ettelbrück <hbruckynews@gmx.de>
Tested-by: NBrian Beardall <brian@rapsure.net>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

After redefining CONFIG_PM to depend on (CONFIG_PM_SLEEP ||
CONFIG_PM_RUNTIME) the CONFIG_PM_OPS option is redundant and can be
replaced with CONFIG_PM.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The function acpi_hibernation_enter() is always called with
interrupts off, so it doesn't need to switch them off and on.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The function do_suspend_lowlevel() is specific to x86 and defined in
assembly code, so it should be called from the x86 low-level suspend
code rather than from acpi_suspend_enter().

Merge do_suspend_lowlevel() into the x86's acpi_save_state_mem() and
change the name of the latter to acpi_suspend_lowlevel(), so that the
function's purpose is better reflected by its name.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Since acpi_save_state_mem() is only called by acpi_suspend_enter()
if the target sleep state is S3, it's better to call it under the
switch (acpi_state), right before do_suspend_lowlevel().
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Move the low-level resume completion message to the point where
control goes back to acpi_suspend_enter() during resume and change
it so that it's more informative.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The function acpi_suspend_enter() is always called with interrupts
off, so it doesn't need to switch them off and on.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The function acpi_restore_state_mem() has never been and most likely
never will be used, so remove it.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Use the unified trampoline allocation setup to allocate and install
the ACPI wakeup code in low memory.
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
LKML-Reference: <4D5DFBE4.7090104@intel.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Matthieu Castet <castet.matthieu@free.fr>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>

It turns out that some device drivers map pages from the ACPI NVS region
during resume using ioremap(), which conflicts with ioremap_cache() used
for mapping those pages by the NVS save/restore code in nvs.c.

Make the NVS pages mapped by the code in nvs.c be unmapped before device
drivers' resume routines run.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Apparently, Averatec AV1020-ED2 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=16396#c86Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

When ioremap() fails (which might happen for some reason), we nicely
oops in suspend_nvs_save() due to NULL dereference by memcpy() in there.
Fail gracefully instead.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

The saving of the NVS memory area during suspend and restoring it
during resume causes problems to appear on Sony Vaio VGN-NW130D, so
blacklist that machine to avoid those problems.

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=23002Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reported-and-tested-by: NAdriano <adriano.vilela@yahoo.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

While at it, fix two checkpatch errors.
Several non-const struct instances constified by this patch were added after
the introduction of platform_suspend_ops in checkpatch.pl's list of "should
be const" structs (79404849).

Patch against mainline.
Inspired by hunks of the grsecurity patch, updated for newer kernels.
Signed-off-by: NLionel Debroux <lionel_debroux@yahoo.fr>
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Patch against mainline.

Changes since v1: added one hunk; no longer adding "const" qualifier to
pointers in platform_hibernation_ops after seeing
b4144e4f.
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Sony Vaio VPCEB1Z1E is reported to require acpi_sleep=nonvs for
suspend/resume to work on it correctly, so blacklist it.
Reported-by: NEmanuele Bigiarini <pulmro@gmail.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

Only used in one file so should be static.
Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

There is a number of problems with acpi_pm_device_sleep_state() now.
First, if _S0W is not defined, it prevents devices from being put
into D3 by PCI runtime PM, which shouldn't happen.  Second, it
shouldn't use adev->wakeup.state.enabled, because if it's set, it
only means that either the device is permanently enabled to wake up
the system, or that it has been enabled to do that through
/proc/acpi/wakeup.  Finally, it should be compiled if CONFIG_PM_SLEEP
is not set, so that PCI runtime PM works correctly in that case.
Fix these problems.
Reported-by: NMatthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

Commit 2a6b6976 (ACPI: Store NVS
state even when entering suspend to RAM) changed the ACPI suspend
to RAM code so that the NVS memory area is always unconditionally
saved during suspend and restored during resume, since some systems
evidently need that for the suspend-resume to work on them.  However,
it turned out that this change broke suspend-resume on a few systems,
so commit 72ad5d77 (ACPI / Sleep:
Allow the NVS saving to be skipped during suspend to RAM) introduced
the acpi_sleep=nonvs command line switch to allow their users to
work around this issue.  To keep track of the systems that require
this workaround and to make the life of their users slightly easier
blacklist them in acpisleep_dmi_table[].

https://bugzilla.kernel.org/show_bug.cgi?id=16396Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

Commit 2a6b6976
(ACPI: Store NVS state even when entering suspend to RAM) caused the
ACPI suspend code save the NVS area during suspend and restore it
during resume unconditionally, although it is known that some systems
need to use acpi_sleep=s4_nonvs for hibernation to work.  To allow
the affected systems to avoid saving and restoring the NVS area
during suspend to RAM and resume, introduce kernel command line
option acpi_sleep=nonvs and make acpi_sleep=s4_nonvs work as its
alias temporarily (add acpi_sleep=s4_nonvs to the feature removal
file).

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16396 .
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reported-and-tested-by: Ntomas m <tmezzadra@gmail.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

ACPICA uses reference counters to avoid disabling GPEs too early in
case they have been enabled for many times.  This is done separately
for runtime and for wakeup, but the wakeup GPE reference counter is
not really necessary, because GPEs are only enabled to wake up the
system at the hardware level by acpi_enter_sleep_state().  Thus it
only is necessary to set the corresponding bits in the wakeup enable
masks of these GPEs' registers right before the system enters a sleep
state.  Moreover, the GPE wakeup enable bits can only be set when the
target sleep state of the system is known and they need to be cleared
immediately after wakeup regardless of how many wakeup devices are
associated with a given GPE.

On the basis of the above observations, introduce function
acpi_gpe_wakeup() to be used for setting or clearing the enable bit
corresponding to a given GPE in its enable register's enable_for_wake
mask.  Modify the ACPI suspend and wakeup code the use
acpi_gpe_wakeup() instead of acpi_{enable|disable}_gpe() to set
and clear GPE enable bits in their registers' enable_for_wake masks
during system transitions to a sleep state and back to the working
state, respectively.  [This will allow us to drop the third
argument of acpi_{enable|disable}_gpe() and simplify the GPE
handling code.]
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The function acpi_suspend_finish() is not necessary any more, because
acpi_pm_finish() can be used instead of it just fine.  Remove it.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

Some hibernation and suspend routines can be merged, which reduces
the complexity of code a bit.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

To simplify the enabling of wakeup devices during system suspend and
hibernation, merge acpi_enable_wakeup_device_prep() with
acpi_disable_wakeup_device() and remove unnecessary (and no longer
valid) comments from the latter.  Rename acpi_enable_wakeup_device()
to acpi_enable_wakeup_devices() and acpi_disable_wakeup_device()
to acpi_disable_wakeup_devices(), because these functions usually
operate on multiple device objects.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

There is no reason why acpi_enable_wakeup_device() should be called
with interrupts disabled, because it doesn't access hardware.  Thus
it is possible to move it next to acpi_enable_wakeup_device_prep()
and make the ACPI suspend, hibernate and poweroff code more
straightforward.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

If suspending of devices fails or system suspend is tested in the
"devices" mode, the memory allocated for storing a copy of the ACPI
NVS area will not be freed, because acpi_pm_finish() is not called
in that case.  Fix this by moving the suspend_nvs_free() call to
acpi_pm_end().
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

https://bugzilla.kernel.org/show_bug.cgi?id=13931 describes a bug where
a system fails to successfully resume after the second suspend. Maxim
Levitsky discovered that this could be rectified by forcibly saving
and restoring the ACPI non-volatile state. The spec indicates that this
is only required for S4, but testing the behaviour of Windows by adding
an ACPI NVS region to qemu's e820 map and registering a custom memory
read/write handler reveals that it's saved and restored even over suspend
to RAM. We should mimic that behaviour to avoid other broken platforms.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Saving platform non-volatile state may be required for suspend to RAM as
well as hibernation. Move it to more generic code.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Tested-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The names of the functions used for blocking/unblocking EC
transactions during suspend/hibernation suggest that the transactions
are suspended and resumed by them, while in fact they are disabled
and enabled.  Rename the functions (and the flag used by them) to
better reflect what they really do.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

There still is a race that may result in suspending the system in
the middle of an EC transaction in progress, which leads to problems
(like the kernel thinking that the ACPI global lock is held during
resume while in fact it's not).

To remove the race condition, modify the ACPI platform suspend and
hibernate callbacks so that EC transactions are blocked right after
executing the _PTS global control method and are allowed to happen
again right after the low-level wakeup.

Introduce acpi_pm_freeze() that will disable GPEs, wait until the
event queues are empty and block EC transactions.  Use it wherever
GPEs are disabled in preparation for switching local interrupts off.
Introduce acpi_pm_thaw() that will allow EC transactions to happen
again and enable runtime GPEs.  Use it to balance acpi_pm_freeze()
wherever necessary.

In addition to that use acpi_ec_resume_transactions_early() to
unblock EC transactions as early as reasonably possible during
resume.  Also unblock EC transactions in acpi_hibernation_finish()
and in the analogous suspend routine to make sure that the EC
transactions are enabled in all error paths.

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=14668Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reported-and-tested-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The ACPI spec tells us that the firmware will reenable SCI_EN on resume.
Reality disagrees in some cases. The ACPI spec tells us that the only way
to set SCI_EN is via an SMM call.
https://bugzilla.kernel.org/show_bug.cgi?id=13745 shows us that doing so
may break machines. Tracing the ACPI calls made by Windows shows that it
unconditionally sets SCI_EN on resume with a direct register write, and
therefore the overwhelming probability is that everything is fine with
this behaviour.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Tested-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

Duplicate entries ended up acpisleep_dmi_table[] by accident.
They don't hurt functionality, but they are ugly, so let's get
rid of them.

Cc: stable@kernel.org
Signed-off-by: NAlex Chiang <achiang@canonical.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add Dell Studio models (1558, 1557, 1555) to the 'set_sci_en_on_resume'
list to fix hang on resume.

BugLink: http://bugs.launchpad.net/bugs/553498Signed-off-by: NKamal Mostafa <kamal@canonical.com>
Acked-by: NAlex Chiang <achiang@canonical.com>
Cc: stable@kernel.org
Signed-off-by: NLen Brown <len.brown@intel.com>

Multiple Lenovo ThinkPad models with Intel Core i5/i7 CPUs can
successfully suspend/resume once, and then hang on the second s/r
cycle.

We got confirmation that this was due to a BIOS defect. The BIOS
did not properly set SCI_EN coming out of S3. The BIOS guys
hinted that The Other Leading OS ignores the fact that hardware
owns the bit and sets it manually.

In any case, an existing DMI table exists for machines where this
defect is a known problem. Lenovo promise to fix their BIOS, but
for folks who either won't or can't upgrade their BIOS, allow
Linux to workaround the issue.

https://bugzilla.kernel.org/show_bug.cgi?id=15407
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/532374

Confirmed by numerous testers in the launchpad bug that using
acpi_sleep=sci_force_enable fixes the issue. We add the machines
to acpisleep_dmi_table[] to automatically enable this workaround.

Cc: stable@kernel.org
Cc: Colin King <colin.king@canonical.com>
Signed-off-by: NAlex Chiang <achiang@canonical.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

There is a race between resume from hibernation and the EC driver
that may result in restoring the hibernation image in the middle of
an EC transaction in progress, which in turn may lead to
unpredictable behavior of the platform.

To remove that race condition, add a helpers for suspending and
resuming EC transactions in a safe way to be executed by the ACPI
platform hibernate pre-restore and restore cleanup callbacks.

http://bugzilla.kernel.org/show_bug.cgi?id=14668Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reported-and-tested-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

ACPI GPEs may map to multiple devices.  The current GPE interface
only provides a mechanism for enabling and disabling GPEs, making
it difficult to change the state of GPEs at runtime without extensive
cooperation between devices.

Add an API to allow devices to indicate whether or not they want
their device's GPE to be enabled for both runtime and wakeup events.

Remove the old GPE type handling entirely, which gets rid of various
quirks, like the implicit disabling with GPE type setting. This
requires a small amount of rework in order to ensure that non-wake
GPEs are enabled by default to preserve existing behaviour.

Based on patches from Matthew Garrett <mjg@redhat.com>.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Introduce kernel parameter acpi_sleep=sci_force_enable

some laptop requires SCI_EN being set directly on resume,
or else they hung somewhere in the resume code path.

We already have a blacklist for these laptops but we still need
this option, especially when debugging some suspend/resume problems,
in case there are systems that need this workaround and are not yet
in the blacklist.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

...else ACPI thermal controls fail after resume.

http://bugzilla.kernel.org/show_bug.cgi?id=13745Signed-off-by: NLen Brown <len.brown@intel.com>