On Thursday, December 19, 2013 08:22:08 PM H. Peter Anvin wrote:
> On 12/19/2013 08:05 PM, joeyli wrote:
> > Then that means the priority of PNP0B0x is higher then "CMOS RTC Not
> > Present" flag. ACPI spec doesn't have clear definition on this.
>
> According to the Microsoft requirements documents, such a platform is
> broken and shouldn't exist.
Is this a public document?
Probably not but if, a pointer in this thread would help.
Does Microsoft mention ACPI Time and Alarm Device interface in
such a document already?
I expect that future platforms will make more and more use of the
ACPI/EFI specified time functions.
It's probably up to Microsoft requiring this at some point of time,
then this stuff will work reliable, possibly others will not anymore.
Given the fact that there are machines which implement this interface
already and it is likely that more and more will, IMHO a first
implementation of this stuff in the kernel, even there are broken BIOSes
around, makes *a lot of* sense.
I suggest a whitelist, however it looks like:
-> platforms which do not have a PNP0B0x device?
-> dmi whitelist working platforms
-> Extend it later with conditions where we know things work as expected
best also introduce an acpi=enable/disable_tad (or simlar) boot param which
overrides white/blacklisting.
This will allow users to make use of this which may otherwise run into
problems and it will also allow easier testing and feedback
how reliable latest BIOS implementations are.
Thomas
--
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
