|
@@ -47,6 +47,31 @@
|
|
#define _COMPONENT ACPI_UTILITIES
|
|
#define _COMPONENT ACPI_UTILITIES
|
|
ACPI_MODULE_NAME("utosi")
|
|
ACPI_MODULE_NAME("utosi")
|
|
|
|
|
|
|
|
+/******************************************************************************
|
|
|
|
+ *
|
|
|
|
+ * ACPICA policy for new _OSI strings:
|
|
|
|
+ *
|
|
|
|
+ * It is the stated policy of ACPICA that new _OSI strings will be integrated
|
|
|
|
+ * into this module as soon as possible after they are defined. It is strongly
|
|
|
|
+ * recommended that all ACPICA hosts mirror this policy and integrate any
|
|
|
|
+ * changes to this module as soon as possible. There are several historical
|
|
|
|
+ * reasons behind this policy:
|
|
|
|
+ *
|
|
|
|
+ * 1) New BIOSs tend to test only the case where the host responds TRUE to
|
|
|
|
+ * the latest version of Windows, which would respond to the latest/newest
|
|
|
|
+ * _OSI string. Not responding TRUE to the latest version of Windows will
|
|
|
|
+ * risk executing untested code paths throughout the DSDT and SSDTs.
|
|
|
|
+ *
|
|
|
|
+ * 2) If a new _OSI string is recognized only after a significant delay, this
|
|
|
|
+ * has the potential to cause problems on existing working machines because
|
|
|
|
+ * of the possibility that a new and different path through the ASL code
|
|
|
|
+ * will be executed.
|
|
|
|
+ *
|
|
|
|
+ * 3) New _OSI strings are tending to come out about once per year. A delay
|
|
|
|
+ * in recognizing a new string for a significant amount of time risks the
|
|
|
|
+ * release of another string which only compounds the initial problem.
|
|
|
|
+ *
|
|
|
|
+ *****************************************************************************/
|
|
/*
|
|
/*
|
|
* Strings supported by the _OSI predefined control method (which is
|
|
* Strings supported by the _OSI predefined control method (which is
|
|
* implemented internally within this module.)
|
|
* implemented internally within this module.)
|