Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6

* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (123 commits)
  dock: make dock driver not a module
  ACPI: fix ia64 build warning
  ACPI: hack around sysfs warning with link order
  ACPI suspend: fix build warning when CONFIG_ACPI_SLEEP=n
  intel_menlo: fix build warning
  panasonic-laptop: fix build
  ACPICA: Update version to 20080926
  ACPICA: Add support for zero-length buffer-to-string conversions
  ACPICA: New: Validation for predefined ACPI methods/objects
  ACPICA: Fix for implicit return compatibility
  ACPICA: Fixed a couple memory leaks associated with "implicit return"
  ACPICA: Optimize buffer allocation procedure
  ACPICA: Fix possible memory leak, error exit path
  ACPICA: Fix fault after mem allocation failure in AML parser
  ACPICA: Remove unused ACPI register bit definition
  ACPICA: Update version to 20080829
  ACPICA: Fix possible memory leak in acpi_ns_get_external_pathname
  ACPICA: Cleanup for internal Reference Object
  ACPICA: Update comments - no functional changes
  ACPICA: Update for Reference ACPI_OPERAND_OBJECT
  ...

1 files changed, 18 insertions, 26 deletions

diff --git a/drivers/acpi/hardware/hwsleep.c b/drivers/acpi/hardware/hwsleep.c
index dba3cfbe8cba..25dccdf179b9 100644
--- a/drivers/acpi/hardware/hwsleep.c
+++ b/drivers/acpi/hardware/hwsleep.c
@@ -78,19 +78,17 @@ acpi_set_firmware_waking_vector(acpi_physical_address physical_address)
                 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_physical_address * physical_address)
         }
 
         /* 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);
 }
@@ -627,6 +612,13 @@ acpi_status acpi_leave_sleep_state(u8 sleep_state)
         }
         /* TBD: _WAK "sometimes" returns stuff - do we want to look at it? */
 
+        /*
+         * Some BIOSes assume that WAK_STS will be cleared on resume and use
+         * it to determine whether the system is rebooting or resuming. Clear
+         * it for compatibility.
+         */
+        acpi_set_register(ACPI_BITREG_WAKE_STATUS, 1);
+
         acpi_gbl_system_awake_and_running = TRUE;
 
         /* Enable power button */