lk/linux-kernel-test
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

ACPI: delete OSI(Linux) DMI dmesg spam

Browse Source 
Linux will continue to ignore OSI(Linux),
except for a white-list containing a few systems.

So delete the black-list,
and stop soliciting user-feedback on the console.

Signed-off-by: Len Brown <len.brown@intel.com>
This commit is contained in:
Len Brown
2008-11-08 01:21:10 -05:00
parent 95a28ed086
commit a6e0887f21
2 changed files with 30 additions and 475 deletions
Download Patch File Download Diff File Expand all files Collapse all files

104
drivers/acpi/osl.c
View File

@@ -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;
}