summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorMatthew Garrett <mjg@redhat.com>2010-05-11 13:49:25 -0400
committerGreg Kroah-Hartman <gregkh@suse.de>2010-08-02 10:26:45 -0700
commiteb1c6217703d8cbc1c41510e393232a3c06d1a64 (patch)
treec7b4b39da51e642ecedb237f91828b28c08e49b6 /include
parent75676db2d5fe83904ca91c6c40ac81aad54b6493 (diff)
downloadlwn-eb1c6217703d8cbc1c41510e393232a3c06d1a64.tar.gz
lwn-eb1c6217703d8cbc1c41510e393232a3c06d1a64.zip
ACPI: Unconditionally set SCI_EN on resume
commit b6dacf63e9fb2e7a1369843d6cef332f76fca6a3 upstream. The ACPI spec tells us that the firmware will reenable SCI_EN on resume. Reality disagrees in some cases. The ACPI spec tells us that the only way to set SCI_EN is via an SMM call. https://bugzilla.kernel.org/show_bug.cgi?id=13745 shows us that doing so may break machines. Tracing the ACPI calls made by Windows shows that it unconditionally sets SCI_EN on resume with a direct register write, and therefore the overwhelming probability is that everything is fine with this behaviour. Signed-off-by: Matthew Garrett <mjg@redhat.com> Tested-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com> Cc: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'include')
-rw-r--r--include/linux/acpi.h1
1 files changed, 0 insertions, 1 deletions
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index b926afe8c03e..87ca4913294c 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -251,7 +251,6 @@ int acpi_check_mem_region(resource_size_t start, resource_size_t n,
void __init acpi_no_s4_hw_signature(void);
void __init acpi_old_suspend_ordering(void);
void __init acpi_s4_no_nvs(void);
-void __init acpi_set_sci_en_on_resume(void);
#endif /* CONFIG_PM_SLEEP */
struct acpi_osc_context {