diff options
author | Zhao Yakui <yakui.zhao@intel.com> | 2008-10-17 14:22:27 -0400 |
---|---|---|
committer | Len Brown <len.brown@intel.com> | 2008-10-18 01:01:12 -0400 |
commit | 8fd145917fb62368a9b80db59562c20576238f5a (patch) | |
tree | 42b81ee305b6f35e98aed2690f696b32cb5c864b /drivers/acpi | |
parent | 3fa8749e584b55f1180411ab1b51117190bac1e5 (diff) |
ACPI: Ingore the RESET_REG_SUP bit when using ACPI reset mechanism
According to ACPI 3.0, FADT.flags.RESET_REG_SUP indicates
whether the ACPI reboot mechanism is supported.
However, some boxes have this bit clear, have 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.
Here we stop checking RESET_REG_SUP.
Instead, 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
http://bugzilla.kernel.org/show_bug.cgi?id=7299
http://bugzilla.kernel.org/show_bug.cgi?id=1148
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Diffstat (limited to 'drivers/acpi')
-rw-r--r-- | drivers/acpi/reboot.c | 25 |
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) | |||
15 | 15 | ||
16 | rr = &acpi_gbl_FADT.reset_register; | 16 | rr = &acpi_gbl_FADT.reset_register; |
17 | 17 | ||
18 | /* Is the reset register supported? */ | 18 | /* |
19 | if (!(acpi_gbl_FADT.flags & ACPI_FADT_RESET_REGISTER) || | 19 | * Is the ACPI reset register supported? |
20 | rr->bit_width != 8 || rr->bit_offset != 0) | 20 | * |
21 | * According to ACPI 3.0, FADT.flags.RESET_REG_SUP indicates | ||
22 | * whether the ACPI reset mechanism is supported. | ||
23 | * | ||
24 | * However, some boxes have this bit clear, yet a valid | ||
25 | * ACPI_RESET_REG & RESET_VALUE, and ACPI reboot is the only | ||
26 | * mechanism that works for them after S3. | ||
27 | * | ||
28 | * This suggests that other operating systems may not be checking | ||
29 | * the RESET_REG_SUP bit, and are using other means to decide | ||
30 | * whether to use the ACPI reboot mechanism or not. | ||
31 | * | ||
32 | * So when acpi reboot is requested, | ||
33 | * only the reset_register is checked. If the following | ||
34 | * conditions are met, it indicates that the reset register is supported. | ||
35 | * a. reset_register is not zero | ||
36 | * b. the access width is eight | ||
37 | * c. the bit_offset is zero | ||
38 | */ | ||
39 | if (!(rr->address) || rr->bit_width != 8 || rr->bit_offset != 0) | ||
21 | return; | 40 | return; |
22 | 41 | ||
23 | reset_value = acpi_gbl_FADT.reset_value; | 42 | reset_value = acpi_gbl_FADT.reset_value; |