summaryrefslogtreecommitdiff
path: root/drivers/acpi
diff options
context:
space:
mode:
authorLen Brown <len.brown@intel.com>2008-10-22 23:20:02 -0400
committerLen Brown <len.brown@intel.com>2008-10-22 23:20:02 -0400
commitebd7e45f6d27556c94216024212a462aaf899ecb (patch)
treea09c89eb3e2a0a5a41eb94d496763b720e1c949e /drivers/acpi
parent462af435b3d8c682eb86e79d6a42ed62d183c317 (diff)
parent8fd145917fb62368a9b80db59562c20576238f5a (diff)
Merge branch 'bugzilla-11481' into test
Diffstat (limited to 'drivers/acpi')
-rw-r--r--drivers/acpi/reboot.c25
1 files changed, 22 insertions, 3 deletions
diff --git a/drivers/acpi/reboot.c b/drivers/acpi/reboot.c
index a6b662c00b67..755baf2ca70a 100644
--- a/drivers/acpi/reboot.c
+++ b/drivers/acpi/reboot.c
@@ -15,9 +15,28 @@ void acpi_reboot(void)
rr = &acpi_gbl_FADT.reset_register;
- /* Is the reset register supported? */
- if (!(acpi_gbl_FADT.flags & ACPI_FADT_RESET_REGISTER) ||
- rr->bit_width != 8 || rr->bit_offset != 0)
+ /*
+ * Is the ACPI reset register supported?
+ *
+ * According to ACPI 3.0, FADT.flags.RESET_REG_SUP indicates
+ * whether the ACPI reset mechanism is supported.
+ *
+ * However, some boxes have this bit clear, yet a valid
+ * ACPI_RESET_REG & RESET_VALUE, and ACPI reboot is the only
+ * mechanism that works for them after S3.
+ *
+ * This suggests that other operating systems may not be checking
+ * the RESET_REG_SUP bit, and are using other means to decide
+ * whether to use the ACPI reboot mechanism or not.
+ *
+ * So when acpi reboot is requested,
+ * only the reset_register is checked. If the following
+ * conditions are met, it indicates that the reset register is supported.
+ * a. reset_register is not zero
+ * b. the access width is eight
+ * c. the bit_offset is zero
+ */
+ if (!(rr->address) || rr->bit_width != 8 || rr->bit_offset != 0)
return;
reset_value = acpi_gbl_FADT.reset_value;