--- /dev/null
+From a6629105dd03d370fcb31e97bddf223fa4bb651e Mon Sep 17 00:00:00 2001
+From: Rafael J. Wysocki <rjw@sisk.pl>
+Date: Sat, 6 Sep 2008 13:13:01 +0200
+Subject: ACPI suspend: Always use the 32-bit waking vector
+
+From: Rafael J. Wysocki <rjw@sisk.pl>
+
+commit a6629105dd03d370fcb31e97bddf223fa4bb651e upstream.
+
+According to the ACPI specification 2.0c and later, the 64-bit waking vector
+should be cleared and the 32-bit waking vector should be used, unless we want
+the wake-up code to be called by the BIOS in Protected Mode. Moreover, some
+systems (for example HP dv5-1004nr) are known to fail to resume if the 64-bit
+waking vector is used. Therefore, modify the code to clear the 64-bit waking
+vector, for FACS version 1 or greater, and set the 32-bit one before suspend.
+
+http://bugzilla.kernel.org/show_bug.cgi?id=11368
+
+Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
+Signed-off-by: Len Brown <len.brown@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/acpi/hardware/hwsleep.c | 37 +++++++++++--------------------------
+ 1 file changed, 11 insertions(+), 26 deletions(-)
+
+--- a/drivers/acpi/hardware/hwsleep.c
++++ b/drivers/acpi/hardware/hwsleep.c
+@@ -78,19 +78,17 @@ acpi_set_firmware_waking_vector(acpi_phy
+ return_ACPI_STATUS(status);
+ }
+
+- /* Set the vector */
++ /*
++ * According to the ACPI specification 2.0c and later, the 64-bit
++ * waking vector should be cleared and the 32-bit waking vector should
++ * be used, unless we want the wake-up code to be called by the BIOS in
++ * Protected Mode. Some systems (for example HP dv5-1004nr) are known
++ * to fail to resume if the 64-bit vector is used.
++ */
++ if (facs->version >= 1)
++ facs->xfirmware_waking_vector = 0;
+
+- if ((facs->length < 32) || (!(facs->xfirmware_waking_vector))) {
+- /*
+- * ACPI 1.0 FACS or short table or optional X_ field is zero
+- */
+- facs->firmware_waking_vector = (u32) physical_address;
+- } else {
+- /*
+- * ACPI 2.0 FACS with valid X_ field
+- */
+- facs->xfirmware_waking_vector = physical_address;
+- }
++ facs->firmware_waking_vector = (u32)physical_address;
+
+ return_ACPI_STATUS(AE_OK);
+ }
+@@ -134,20 +132,7 @@ acpi_get_firmware_waking_vector(acpi_phy
+ }
+
+ /* Get the vector */
+-
+- if ((facs->length < 32) || (!(facs->xfirmware_waking_vector))) {
+- /*
+- * ACPI 1.0 FACS or short table or optional X_ field is zero
+- */
+- *physical_address =
+- (acpi_physical_address) facs->firmware_waking_vector;
+- } else {
+- /*
+- * ACPI 2.0 FACS with valid X_ field
+- */
+- *physical_address =
+- (acpi_physical_address) facs->xfirmware_waking_vector;
+- }
++ *physical_address = (acpi_physical_address)facs->firmware_waking_vector;
+
+ return_ACPI_STATUS(AE_OK);
+ }
--- /dev/null
+From 4fb507b6b764195bb7821cf2baa988f6eb677d30 Mon Sep 17 00:00:00 2001
+From: Rafael J. Wysocki <rjw@sisk.pl>
+Date: Tue, 14 Oct 2008 22:54:06 +0200
+Subject: ACPI suspend: Blacklist HP xw4600 Workstation for old code ordering
+
+From: Rafael J. Wysocki <rjw@sisk.pl>
+
+commit 4fb507b6b764195bb7821cf2baa988f6eb677d30 upstream
+
+HP xw4600 Workstation is known to require the "old" (ie. compatible
+with ACPI 1.0) suspend code ordering, so blacklist it for this
+purpose.
+
+Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
+Tested-by: John Brown <john.brown3@hp.com>
+Signed-off-by: Len Brown <len.brown@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/acpi/sleep/main.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/acpi/sleep/main.c
++++ b/drivers/acpi/sleep/main.c
+@@ -298,6 +298,14 @@ static struct dmi_system_id __initdata a
+ DMI_MATCH(DMI_BOARD_NAME, "KN9 Series(NF-CK804)"),
+ },
+ },
++ {
++ .callback = init_old_suspend_ordering,
++ .ident = "HP xw4600 Workstation",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "HP xw4600 Workstation"),
++ },
++ },
+ {},
+ };
+ #endif /* CONFIG_SUSPEND */
--- /dev/null
+From d0c71fe7ebc180f1b7bc7da1d39a07fc19eec768 Mon Sep 17 00:00:00 2001
+From: Rafael J. Wysocki <rjw@sisk.pl>
+Date: Sat, 4 Oct 2008 00:05:05 +0200
+Subject: ACPI Suspend: Enable ACPI during resume if SCI_EN is not set
+
+From: Rafael J. Wysocki <rjw@sisk.pl>
+
+commit d0c71fe7ebc180f1b7bc7da1d39a07fc19eec768 upstream.
+
+On some machines, like for example MSI Wind U100, the BIOS doesn't
+enable ACPI before returning control to the OS, which sometimes
+causes resume to fail. This is against the ACPI specification,
+which clearly states that "When the platform is waking from an S1, S2
+or S3 state, OSPM assumes the hardware is already in the ACPI mode
+and will not issue an ACPI_ENABLE", but it won't hurt to check the
+SCI_EN bit and enable ACPI during resume from S3 if this bit is not
+set.
+
+Fortunately, we already have acpi_enable() for that, so use it in the
+resume code path, before executing _BFS, in analogy with the
+resume-from-hibernation code path.
+
+NOTE: We aren't supposed to set SCI_EN directly, because it's owned
+by the hardware.
+
+Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
+Acked-by: Pavel Machek <pavel@suse.cz>
+Signed-off-by: Len Brown <len.brown@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/acpi/sleep/main.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/acpi/sleep/main.c
++++ b/drivers/acpi/sleep/main.c
+@@ -200,6 +200,8 @@ static int acpi_suspend_enter(suspend_st
+ break;
+ }
+
++ /* If ACPI is not enabled by the BIOS, we need to enable it here. */
++ acpi_enable();
+ /* Reprogram control registers and execute _BFS */
+ acpi_leave_sleep_state_prep(acpi_state);
+
anon_vma_prepare-properly-lock-even-newly-allocated-entries.patch
hvc_console-fix-free_irq-in-spinlocked-section.patch
regression-inclusion-of-linux-module.h-triggers-a-compiler-warning.patch
+acpi-suspend-enable-acpi-during-resume-if-sci_en-is-not-set.patch
+acpi-suspend-blacklist-hp-xw4600-workstation-for-old-code-ordering.patch
+acpi-suspend-always-use-the-32-bit-waking-vector.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
