aboutsummaryrefslogtreecommitdiff
path: root/drivers/acpi/reboot.c
diff options
context:
space:
mode:
authorIngo Molnar <mingo@elte.hu>2008-11-17 10:46:18 +0100
committerIngo Molnar <mingo@elte.hu>2008-11-17 10:46:18 +0100
commit9dacc71ff31a008d1e689fc824d31f6696454f68 (patch)
treeb792f9c30008e1ed469a73ead4339fdf8a50a5ce /drivers/acpi/reboot.c
parent19f47c634ea8c5a10ff7bb1a08c52fd0f49bc54c (diff)
parent9bf1a2445f3c569098b8de7097ca324e65abecc2 (diff)
Merge commit 'v2.6.28-rc5' into x86/cleanups
Diffstat (limited to 'drivers/acpi/reboot.c')
-rw-r--r--drivers/acpi/reboot.c25
1 files changed, 3 insertions, 22 deletions
diff --git a/drivers/acpi/reboot.c b/drivers/acpi/reboot.c
index 755baf2ca70..a6b662c00b6 100644
--- a/drivers/acpi/reboot.c
+++ b/drivers/acpi/reboot.c
@@ -15,28 +15,9 @@ void acpi_reboot(void)
rr = &acpi_gbl_FADT.reset_register;
- /*
- * 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)
+ /* Is the reset register supported? */
+ if (!(acpi_gbl_FADT.flags & ACPI_FADT_RESET_REGISTER) ||
+ rr->bit_width != 8 || rr->bit_offset != 0)
return;
reset_value = acpi_gbl_FADT.reset_value;