> > using _OSI is not "a similar method to Windows". > > The BIOS does not need to invoke _OSI to determine if > > it should expose a properly functioning ACPI reset or not. > > Windows XP simply demanded it, and the box failed WHQL > > if it did not work. > > http://download.microsoft.com/download/7/E/7/7E7662CF-CBEA-470B-A97E-CE7CE0D98DC2/WinACPI_OSI.docx > was what I was referring to: > > "By using the _OSI method, ASL writers can easily determine the version > of the ACPI interfaces that the host operating system supports. This > versioning method provides a solution for creating firmware that can > support future operating systems and enable the operating system to > change behavior based on the requested interface levels." > > We know that this is used for deciding whether or not to block system IO > accesses, but it wouldn't surprise me if it's also used to determine > other functionality like whether or not the ACPI interface is used for > rebooting. I've looked at _OSI use in over a hundred DSDTs and never seen run-time re-configuration of reset support. I do not think the BIOS has a run-time decision to make here. If a box is designed to support Windows XP and newer, it is likely that ACPI_RESET is simply valid and XP blindly uses it. If reset fails, the box doesn't pass WHQL and the box is fixed. If W2K is run on that box, ACPI_RESET is still valid, just that W2K chooses to not write to it. > > Further, there is no _guarantee_ that a BIOS will invoke _OSI > > at all, let alone a _rule_ for what _OSI() strings the BIOS > > will choose to query to trigger its Windows specific > > compatibility hooks -- even if common practice is for > > a desktop BIOS to evaluate _OSI strings in sequence > > up throught he most recent version of Windows it > > knows about... > > It's effectively guaranteed if the system is validated with Windows. today's common industry practice != future guarantee We can't rely on blind use of _OSI to mean "new enough", since it was supported back in W2K era. That means we have to parse the OSI strings. But what happens when a BIOS writer decides to evaluate _OSI("Windows Future") without evaluating any of the old strings we know about? We would disable ACPI reset on such a future box? thanks, -Len -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
