> > can we do it based on the dmi/acpi year? > I think a saner model would be to use a similar method to Windows - > that is, change behaviour based on the OSI calls that the firmware > makes. If the firmware supports Vista, it's probably safe to use the > ACPI reboot method. Andrey Borzenkov's Toshiba Portege 4000 failed to reset with ACPI, which is why we reverted ACPI reset as default in 2008. Toshiba shipped the Portege 4000 in 2002 running with Windows 2000, suggesting that Windows 2000 does not use ACPI reset -- at least not always. When debugging the reset failure in: http://bugzilla.kernel.org/show_bug.cgi?id=11942 Yakui Zhao found that Windows XP writes the ACPI reset register no matter if the FADT says it is valid or not: http://lkml.indiana.edu/hypermail/linux/kernel/0811.0/02272.html At the end of the day, we decided that Linux should honor that bit, but what we learned is that Windows XP apparently uses ACPI reset by default. So it is likely that our DMI exception lists will be minimized by using legacy reset for W2K generation and before; and using ACPI reset for Windows XP generation and after. As Robert Hancock corrected me, XP is _OSI(Windows 2001). But... 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. 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... So I'm more comfortable with DMI, and any year after Windows 2000 is gone is probably reasonable, say 2003. I have no doubt that no matter what we do, we will end up with some exceptions on a blacklist, the goal is simply to minimize those lists. cheers, Len Brown, Intel Open Source Technology Center ps. For CONFIG_ACPI_BLACKLIST_YEAR we chose not to strive for consensus on a hard-coded year, but made it a config option. I'm not a fan of more config options, but that one allowed us to avoid thrashing about what year ACPI should kick in and defer that to the distros. I think it has probably served its purpose now, as Fedora for the last few years has shipped with this option disabled -- enabling ACPI on all systems that present an ACPI BIOS. -- 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
