From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME Date: Fri, 20 Dec 2013 13:25:06 -0800 Message-ID: <52B4B5B2.70306@zytor.com> References: <1387439053-8711-1-git-send-email-jlee@suse.com> <52B309EB.90300@zytor.com> <1387512357.3539.4317.camel@linux-s257.site> <52B3C5F0.1060303@zytor.com> <1387517916.3539.4446.camel@linux-s257.site> <52B4B242.5010002@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <52B4B242.5010002-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org> Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: joeyli Cc: "Rafael J. Wysocki" , Alessandro Zummo , Matt Fleming , Matthew Garrett , Elliott-VXdhtT5mjnY@public.gmane.org, samer.el-haj-mahmoud-VXdhtT5mjnY@public.gmane.org, Oliver Neukum , werner-IBi9RG/b67k@public.gmane.org, trenn-l3A5Bk7waGM@public.gmane.org, JBeulich-IBi9RG/b67k@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Borislav Petkov List-Id: linux-acpi@vger.kernel.org On 12/20/2013 01:10 PM, H. Peter Anvin wrote: > On 12/19/2013 09:38 PM, joeyli wrote: >> >> If don't use EFI time, then the first priority is using ACPI TAD if it >> present. Due to ACPI TAD is a generic acpi device that's need OS parsing >> DSDT table before set system time. >> >> Either move DSDT parser from subsystem initial stage to start_kernel or >> move timekeeping initial to after DSDT be parsed. Which one you think is >> more possible and risk less? Then I will try that way. >> > > I discussed the DSDT/SSDT parsing issue with Rafael and he claims it > would require a lot of restructuring. Unfortunately ACPI is at this > point done rather late, as I understand. All of this is a big problem. > The thing is that we probably need this anyway, because that is how one detects PNP0B0x devices as well. We do need to get away from blindly poking ports 0x70-73. -hpa