summaryrefslogtreecommitdiffstats
path: root/drivers/acpi/osl.c
diff options
context:
space:
mode:
Diffstat (limited to 'drivers/acpi/osl.c')
-rw-r--r--drivers/acpi/osl.c104
1 files changed, 25 insertions, 79 deletions
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 4be252145cb4..c8111424dcb8 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -35,7 +35,6 @@
#include <linux/interrupt.h>
#include <linux/kmod.h>
#include <linux/delay.h>
-#include <linux/dmi.h>
#include <linux/workqueue.h>
#include <linux/nmi.h>
#include <linux/acpi.h>
@@ -97,54 +96,44 @@ static DEFINE_SPINLOCK(acpi_res_lock);
static char osi_additional_string[OSI_STRING_LENGTH_MAX];
/*
- * "Ode to _OSI(Linux)"
+ * The story of _OSI(Linux)
*
- * osi_linux -- Control response to BIOS _OSI(Linux) query.
+ * From pre-history through Linux-2.6.22,
+ * Linux responded TRUE upon a BIOS OSI(Linux) query.
*
- * As Linux evolves, the features that it supports change.
- * So an OSI string such as "Linux" is not specific enough
- * to be useful across multiple versions of Linux. It
- * doesn't identify any particular feature, interface,
- * or even any particular version of Linux...
+ * Unfortunately, reference BIOS writers got wind of this
+ * and put OSI(Linux) in their example code, quickly exposing
+ * this string as ill-conceived and opening the door to
+ * an un-bounded number of BIOS incompatibilities.
*
- * Unfortunately, Linux-2.6.22 and earlier responded "yes"
- * to a BIOS _OSI(Linux) query. When
- * a reference mobile BIOS started using it, its use
- * started to spread to many vendor platforms.
- * As it is not supportable, we need to halt that spread.
+ * For example, OSI(Linux) was used on resume to re-POST a
+ * video card on one system, because Linux at that time
+ * could not do a speedy restore in its native driver.
+ * But then upon gaining quick native restore capability,
+ * Linux has no way to tell the BIOS to skip the time-consuming
+ * POST -- putting Linux at a permanent performance disadvantage.
+ * On another system, the BIOS writer used OSI(Linux)
+ * to infer native OS support for IPMI! On other systems,
+ * OSI(Linux) simply got in the way of Linux claiming to
+ * be compatible with other operating systems, exposing
+ * BIOS issues such as skipped device initialization.
*
- * Today, most BIOS references to _OSI(Linux) are noise --
- * they have no functional effect and are just dead code
- * carried over from the reference BIOS.
- *
- * The next most common case is that _OSI(Linux) harms Linux,
- * usually by causing the BIOS to follow paths that are
- * not tested during Windows validation.
- *
- * Finally, there is a short list of platforms
- * where OSI(Linux) benefits Linux.
- *
- * In Linux-2.6.23, OSI(Linux) is first disabled by default.
- * DMI is used to disable the dmesg warning about OSI(Linux)
- * on platforms where it is known to have no effect.
- * But a dmesg warning remains for systems where
- * we do not know if OSI(Linux) is good or bad for the system.
- * DMI is also used to enable OSI(Linux) for the machines
- * that are known to need it.
+ * So "Linux" turned out to be a really poor chose of
+ * OSI string, and from Linux-2.6.23 onward we respond FALSE.
*
* BIOS writers should NOT query _OSI(Linux) on future systems.
- * It will be ignored by default, and to get Linux to
- * not ignore it will require a kernel source update to
- * add a DMI entry, or a boot-time "acpi_osi=Linux" invocation.
+ * Linux will complain on the console when it sees it, and return FALSE.
+ * To get Linux to return TRUE for your system will require
+ * a kernel source update to add a DMI entry,
+ * or boot with "acpi_osi=Linux"
*/
-#define OSI_LINUX_ENABLE 0
static struct osi_linux {
unsigned int enable:1;
unsigned int dmi:1;
unsigned int cmdline:1;
unsigned int known:1;
-} osi_linux = { OSI_LINUX_ENABLE, 0, 0, 0};
+} osi_linux = { 0, 0, 0, 0};
static void __init acpi_request_region (struct acpi_generic_address *addr,
unsigned int length, char *desc)
@@ -1296,34 +1285,6 @@ acpi_status acpi_os_release_object(acpi_cache_t * cache, void *object)
return (AE_OK);
}
-/**
- * acpi_dmi_dump - dump DMI slots needed for blacklist entry
- *
- * Returns 0 on success
- */
-static int acpi_dmi_dump(void)
-{
-
- if (!dmi_available)
- return -1;
-
- printk(KERN_NOTICE PREFIX "DMI System Vendor: %s\n",
- dmi_get_system_info(DMI_SYS_VENDOR));
- printk(KERN_NOTICE PREFIX "DMI Product Name: %s\n",
- dmi_get_system_info(DMI_PRODUCT_NAME));
- printk(KERN_NOTICE PREFIX "DMI Product Version: %s\n",
- dmi_get_system_info(DMI_PRODUCT_VERSION));
- printk(KERN_NOTICE PREFIX "DMI Board Name: %s\n",
- dmi_get_system_info(DMI_BOARD_NAME));
- printk(KERN_NOTICE PREFIX "DMI BIOS Vendor: %s\n",
- dmi_get_system_info(DMI_BIOS_VENDOR));
- printk(KERN_NOTICE PREFIX "DMI BIOS Date: %s\n",
- dmi_get_system_info(DMI_BIOS_DATE));
-
- return 0;
-}
-
-
/******************************************************************************
*
* FUNCTION: acpi_os_validate_interface
@@ -1350,21 +1311,6 @@ acpi_os_validate_interface (char *interface)
osi_linux.cmdline ? " via cmdline" :
osi_linux.dmi ? " via DMI" : "");
- if (!osi_linux.dmi) {
- if (acpi_dmi_dump())
- printk(KERN_NOTICE PREFIX
- "[please extract dmidecode output]\n");
- printk(KERN_NOTICE PREFIX
- "Please send DMI info above to "
- "linux-acpi@vger.kernel.org\n");
- }
- if (!osi_linux.known && !osi_linux.cmdline) {
- printk(KERN_NOTICE PREFIX
- "If \"acpi_osi=%sLinux\" works better, "
- "please notify linux-acpi@vger.kernel.org\n",
- osi_linux.enable ? "!" : "");
- }
-
if (osi_linux.enable)
return AE_OK;
}
OpenPOWER on IntegriCloud