[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <E99CBA9F97C3D149AA6B19ED2E277C9B01921638@BY2PRD0510MB365.namprd05.prod.outlook.com>
Date: Fri, 28 Dec 2012 20:49:42 +0000
From: Matthew Garrett <matthew.garrett@...ula.com>
To: "H. Peter Anvin" <hpa@...or.com>
CC: "Lee, Chun-Yi" <joeyli.kernel@...il.com>,
"matt.fleming@...el.com" <matt.fleming@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
"Lee, Chun-Yi" <jlee@...e.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Jan Beulich <JBeulich@...e.com>, Len Brown <lenb@...nel.org>,
Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled
On Fri, 2012-12-28 at 12:40 -0800, H. Peter Anvin wrote:
> > I suspect that what we *should* do looks like:
> >
> > 1. If ACPI exports a Time and Alarm Device (ACPI000E) the use it;
> > 2. If ACPI exports an PC/AT device (PNP0B00/1/2) then use it(*);
> > 3. If we have an EFI RTC use it;
> > 4. Probe for a PC/AT RTC device.
In terms of ordering, 3 should probably come before 2 - but that depends
on us actually fixing the issues that are preventing some of these calls
from working. As far as wallclock time goes, EFI is going to be
available to us before we've parsed the DSDT to determine whether
there's any ACPI devices, so we'll almost certainly end up having to use
it at at least some point during boot. Otherwise, agreed.
Powered by blists - more mailing lists