[RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[Lee, Chun-Yi]

This patchset add the timezone support of ACPI TAD and EFI TIME, it
also add codes for adjusting system time base on the timezone value
from EFI TIME services when system boot.

Those patches bring the following changes:

 + Add ACPI driver against ACPI000E ACPI Time and Alarm Device.

 + Add RTC driver of ACPI TAD.

 + Add rtc ioctl functions, RTC_RD_GMTOFF and RTC_SET_GMTOFF, provide
   interface to user space for maintain timezone value in BIOS.
   The GMTOFF names of ioctl functions match with the tm_gmtoff field
   in rtc_time and tm structure in GNU C library.

 + Add rtc ioctl function, RTC_CAPS_READ, provide to user space for
   grab the capabilities value to timezone and daylight of interface.

 + Moved duplicate functions to efi.h header for convert EFI Time.

 + When "CMOS RTC not Present" flag set in FADT, block CMOS RTC interface
   and switch to EFI time services.

 + Adjusting system time base on timezone from EFI time when system boot.

 + Add rtc-tz.txt document.

Please set CONFIG_RTC_DRV_EFI=m and CONFIG_RTC_ACPI_TAD=m to build RTC ACPI
TAD and EFI TIME drivers.For testing, please use "acpi_no_cmos_rtc=1" to set
CMOST RTC not Present flag in FADT to trigger the mechanism for adjust system
time and block CMOS interface.

About the definition of timezone and the format transformation between ACPI,
EFI and tm_gmtoff of GNU. Please check the rtc-tz.txt document in patch.


Jan Beulich (1):
  x86-64/efi: Use EFI to deal with platform wall clock (again)

Lee, Chun-Yi (13):
  rtc-efi: fix decrease day twice when computing year days
  rtc: block registration of rtc-cmos when CMOS RTC Not Present
  ACPI: Add ACPI 5.0 Time and Alarm Device driver
  rtc: Add RTC driver of ACPI Time and Alarm Device
  rtc-efi: register rtc-efi device when EFI enabled
  rtc-efi: add GMTOFF support to rtc_efi
  rtc-efi: set uie_unsupported for indicate rtc-efi doesn't support UIE
  efi: move functions of access efi time to header file for sharing
  rtc: improve and move week day computing function to rtc header
  rtc: switch to get/set rtc time to efi functions if CMOS RTC Not
  efi: adjust system time base on timezone from EFI time services
  Documentation/RTC: add document of ACPI TAD and EFI TIME driver
  acpi: add early parameter to set CMOS RTC Not Present bit for testing

 Documentation/rtc-tz.txt    |  510 +++++++++++++++++++++++++++++++++++++++++++
 arch/x86/kernel/acpi/boot.c |   17 ++
 arch/x86/kernel/rtc.c       |   28 ++-
 arch/x86/mm/pageattr.c      |   10 +-
 arch/x86/platform/efi/efi.c |   89 ++++++--
 drivers/acpi/Makefile       |    3 +
 drivers/acpi/acpi_tad.c     |  176 +++++++++++++++
 drivers/acpi/bus.c          |    3 +
 drivers/acpi/internal.h     |    5 +
 drivers/char/efirtc.c       |   98 ---------
 drivers/rtc/Kconfig         |   12 +-
 drivers/rtc/Makefile        |    1 +
 drivers/rtc/rtc-acpitad.c   |  283 ++++++++++++++++++++++++
 drivers/rtc/rtc-cmos.c      |    9 +
 drivers/rtc/rtc-dev.c       |    4 +
 drivers/rtc/rtc-efi.c       |  177 +++++++---------
 drivers/rtc/rtc-sysfs.c     |    8 +
 include/asm-generic/rtc.h   |   22 ++
 include/linux/acpi.h        |   31 +++
 include/linux/efi.h         |  127 +++++++++++-
 include/linux/rtc.h         |   43 ++++
 include/uapi/linux/rtc.h    |    5 +
 init/main.c                 |   13 +-
 kernel/time.c               |    2 +-
 24 files changed, 1439 insertions(+), 237 deletions(-)
 create mode 100644 Documentation/rtc-tz.txt
 create mode 100644 drivers/acpi/acpi_tad.c
 create mode 100644 drivers/rtc/rtc-acpitad.c

[PATCH 01/14] rtc-efi: fix decrease day twice when computing year days

[Lee, Chun-Yi]

Compared with the logic in rtc_year_days of efirtc.c, the code in
rtc-efi decreases value of day twice when it computing year days.
That's becase rtc_year_days in rtc-lib.c already decrease day for
return the year days from 0 to 365.
---
 drivers/rtc/rtc-efi.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/rtc/rtc-efi.c b/drivers/rtc/rtc-efi.c
index 797aa02..c4c3843 100644
--- a/drivers/rtc/rtc-efi.c
+++ b/drivers/rtc/rtc-efi.c
@@ -35,7 +35,7 @@ static inline int
 compute_yday(efi_time_t *eft)
 {
 	/* efi_time_t.month is in the [1-12] so, we need -1 */
-	return rtc_year_days(eft->day - 1, eft->month - 1, eft->year);
+	return rtc_year_days(eft->day, eft->month - 1, eft->year);
 }
 /*
  * returns day of the week [0-6] 0=Sunday
-- 
1.6.4.2

[PATCH 03/14] rtc: block registration of rtc-cmos when CMOS RTC Not Present

[Lee, Chun-Yi]

We should not acess CMOS address when CMOS RTC Not Present bit set in
FADT. The ee5872be patch didn't avoid rtc-cmos driver loaded when system support
ACPI PNP PNP0B0* devices.
So this patch block the registion of rtc-cmos driver to avoid
user space access RTC through CMOS interface.

Signed-off-by: Lee, Chun-Yi <jlee-IBi9RG/b67k@public.gmane.org>
---
 arch/x86/kernel/rtc.c  |   20 ++++++++++++++++----
 drivers/rtc/rtc-cmos.c |    9 +++++++++
 2 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index ca9622a..9b6c568 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -174,16 +174,27 @@ static __init int add_rtc_cmos(void)
 	    { "PNP0b00", "PNP0b01", "PNP0b02", };
 	struct pnp_dev *dev;
 	struct pnp_id *id;
-	int i;
+	int i = 0;
+	bool found_pnp;
 
 	pnp_for_each_dev(dev) {
 		for (id = dev->id; id; id = id->next) {
 			for (i = 0; i < ARRAY_SIZE(ids); i++) {
-				if (compare_pnp_id(id, ids[i]) != 0)
-					return 0;
+				if (compare_pnp_id(id, ids[i]) != 0) {
+					found_pnp = true;
+					goto found_pnp;
+				}
 			}
 		}
 	}
+
+found_pnp:
+	if (found_pnp) {
+		if (acpi_gbl_FADT.header.revision >= 5 &&
+		    acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC)
+			pr_err(FW_BUG "Found %s device but CMOS RTC Not Present flag set\n", ids[i]);
+		return 0;
+	}
 #endif
 	if (of_have_populated_dt())
 		return 0;
@@ -193,7 +204,8 @@ static __init int add_rtc_cmos(void)
 		return -ENODEV;
 
 #ifdef CONFIG_ACPI
-	if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) {
+	if (acpi_gbl_FADT.header.revision >= 5 &&
+	    acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) {
 		/* This warning can likely go away again in a year or two. */
 		pr_info("ACPI: not registering RTC platform device\n");
 		return -ENODEV;
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index f148762..3a84ca9 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -28,6 +28,9 @@
  * interrupts disabled, holding the global rtc_lock, to exclude those
  * other drivers and utilities on correctly configured systems.
  */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/init.h>
@@ -1144,6 +1147,12 @@ static int __init cmos_init(void)
 {
 	int retval = 0;
 
+	if (acpi_gbl_FADT.header.revision >= 5 &&
+	    acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) {
+		pr_info("ACPI CMOS RTC Not Present detected - not loading\n");
+		return 0;
+	}
+
 #ifdef	CONFIG_PNP
 	retval = pnp_register_driver(&cmos_pnp_driver);
 	if (retval == 0)
-- 
1.6.4.2

Re: [PATCH 03/14] rtc: block registration of rtc-cmos when CMOS RTC Not Present

[H. Peter Anvin]

Where did you find a platform with "no CMOS" set and a PNP RTC? I find the expect behavior in that case to be quite ambiguous and it is not at all clear to me that what you have here is the right thing.

"Lee, Chun-Yi" <joeyli.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>We should not acess CMOS address when CMOS RTC Not Present bit set in
>FADT. The ee5872be patch didn't avoid rtc-cmos driver loaded when
>system support
>ACPI PNP PNP0B0* devices.
>So this patch block the registion of rtc-cmos driver to avoid
>user space access RTC through CMOS interface.
>
>Signed-off-by: Lee, Chun-Yi <jlee-IBi9RG/b67k@public.gmane.org>
>---
> arch/x86/kernel/rtc.c  |   20 ++++++++++++++++----
> drivers/rtc/rtc-cmos.c |    9 +++++++++
> 2 files changed, 25 insertions(+), 4 deletions(-)
>
>diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
>index ca9622a..9b6c568 100644
>--- a/arch/x86/kernel/rtc.c
>+++ b/arch/x86/kernel/rtc.c
>@@ -174,16 +174,27 @@ static __init int add_rtc_cmos(void)
> 	    { "PNP0b00", "PNP0b01", "PNP0b02", };
> 	struct pnp_dev *dev;
> 	struct pnp_id *id;
>-	int i;
>+	int i = 0;
>+	bool found_pnp;
> 
> 	pnp_for_each_dev(dev) {
> 		for (id = dev->id; id; id = id->next) {
> 			for (i = 0; i < ARRAY_SIZE(ids); i++) {
>-				if (compare_pnp_id(id, ids[i]) != 0)
>-					return 0;
>+				if (compare_pnp_id(id, ids[i]) != 0) {
>+					found_pnp = true;
>+					goto found_pnp;
>+				}
> 			}
> 		}
> 	}
>+
>+found_pnp:
>+	if (found_pnp) {
>+		if (acpi_gbl_FADT.header.revision >= 5 &&
>+		    acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC)
>+			pr_err(FW_BUG "Found %s device but CMOS RTC Not Present flag
>set\n", ids[i]);
>+		return 0;
>+	}
> #endif
> 	if (of_have_populated_dt())
> 		return 0;
>@@ -193,7 +204,8 @@ static __init int add_rtc_cmos(void)
> 		return -ENODEV;
> 
> #ifdef CONFIG_ACPI
>-	if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) {
>+	if (acpi_gbl_FADT.header.revision >= 5 &&
>+	    acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) {
> 		/* This warning can likely go away again in a year or two. */
> 		pr_info("ACPI: not registering RTC platform device\n");
> 		return -ENODEV;
>diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
>index f148762..3a84ca9 100644
>--- a/drivers/rtc/rtc-cmos.c
>+++ b/drivers/rtc/rtc-cmos.c
>@@ -28,6 +28,9 @@
>  * interrupts disabled, holding the global rtc_lock, to exclude those
>  * other drivers and utilities on correctly configured systems.
>  */
>+
>+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>+
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/init.h>
>@@ -1144,6 +1147,12 @@ static int __init cmos_init(void)
> {
> 	int retval = 0;
> 
>+	if (acpi_gbl_FADT.header.revision >= 5 &&
>+	    acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) {
>+		pr_info("ACPI CMOS RTC Not Present detected - not loading\n");
>+		return 0;
>+	}
>+
> #ifdef	CONFIG_PNP
> 	retval = pnp_register_driver(&cmos_pnp_driver);
> 	if (retval == 0)

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

Re: [PATCH 03/14] rtc: block registration of rtc-cmos when CMOS RTC Not Present

[joeyli]

Hi hpa, 

於 四，2013-12-19 於 06:38 -0800，H. Peter Anvin 提到：
> Where did you find a platform with "no CMOS" set and a PNP RTC? I find the expect behavior in that case to be quite ambiguous and it is not at all clear to me that what you have here is the right thing.

Actually there doesn't have the box both with "No CMOS" and PNP device. 
I choice to totally block rtc-cmos driver when "No CMOS RTC" because the
definition in ACPI spec:

CMOS RTC Not Present

If set, indicates that the CMOS RTC is either not implemented, or
does not exist at the legacy addresses. OSPM uses the Control
Method Time and Alarm Namespace device instead.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


It suggest us using ACPI TAD interface when this flag present. But, I
agreed your point for this is ambiguous due to ACPI spec didn't clear
define the relationship between PNP0B0x.

Maybe we can do more detail check in cmos_init when "No CMOS RTC" set:
 + check if have ACPI TAD device, then block rtc-cmos
 + check if no ACPI TAD device, but have PNP0B0x, then we use PNP0b0x.

> 
> "Lee, Chun-Yi" <joeyli.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >We should not acess CMOS address when CMOS RTC Not Present bit set in
> >FADT. The ee5872be patch didn't avoid rtc-cmos driver loaded when
> >system support
> >ACPI PNP PNP0B0* devices.
> >So this patch block the registion of rtc-cmos driver to avoid
> >user space access RTC through CMOS interface.
> >
> >Signed-off-by: Lee, Chun-Yi <jlee-IBi9RG/b67k@public.gmane.org>
> >---
> > arch/x86/kernel/rtc.c  |   20 ++++++++++++++++----
> > drivers/rtc/rtc-cmos.c |    9 +++++++++
> > 2 files changed, 25 insertions(+), 4 deletions(-)
> >
...
> >--- a/drivers/rtc/rtc-cmos.c
> >+++ b/drivers/rtc/rtc-cmos.c
> >@@ -28,6 +28,9 @@
> >  * interrupts disabled, holding the global rtc_lock, to exclude those
> >  * other drivers and utilities on correctly configured systems.
> >  */
> >+
> >+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> >+
> > #include <linux/kernel.h>
> > #include <linux/module.h>
> > #include <linux/init.h>
> >@@ -1144,6 +1147,12 @@ static int __init cmos_init(void)
> > {
> > 	int retval = 0;
> > 
> >+	if (acpi_gbl_FADT.header.revision >= 5 &&
> >+	    acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) {
> >+		pr_info("ACPI CMOS RTC Not Present detected - not loading\n");
> >+		return 0;
> >+	}
> >+
> > #ifdef	CONFIG_PNP
> > 	retval = pnp_register_driver(&cmos_pnp_driver);
> > 	if (retval == 0)
> 

Thanks a lot!
Joey Lee

Re: [PATCH 03/14] rtc: block registration of rtc-cmos when CMOS RTC Not Present

[H. Peter Anvin]

On 12/19/2013 07:54 PM, joeyli wrote:
> Hi hpa, 
> 
> 於 四，2013-12-19 於 06:38 -0800，H. Peter Anvin 提到：
>> Where did you find a platform with "no CMOS" set and a PNP RTC? I find the expect behavior in that case to be quite ambiguous and it is not at all clear to me that what you have here is the right thing.
> 
> Actually there doesn't have the box both with "No CMOS" and PNP device. 
> I choice to totally block rtc-cmos driver when "No CMOS RTC" because the
> definition in ACPI spec:
> 
> CMOS RTC Not Present
> 
> If set, indicates that the CMOS RTC is either not implemented, or
> does not exist at the legacy addresses. OSPM uses the Control
> Method Time and Alarm Namespace device instead.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> It suggest us using ACPI TAD interface when this flag present. But, I
> agreed your point for this is ambiguous due to ACPI spec didn't clear
> define the relationship between PNP0B0x.
> 
> Maybe we can do more detail check in cmos_init when "No CMOS RTC" set:
>  + check if have ACPI TAD device, then block rtc-cmos
>  + check if no ACPI TAD device, but have PNP0B0x, then we use PNP0b0x.
> 

I think the only thing we should use that bit for is to inhibit the
last-resort probing of I/O ports 0x70-0x73... if at all.

	-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[H. Peter Anvin]

On 12/18/2013 11:43 PM, Lee, Chun-Yi wrote:
> This patchset add the timezone support of ACPI TAD and EFI TIME, it
> also add codes for adjusting system time base on the timezone value
> from EFI TIME services when system boot.

EFI time is something we used to support and ripped out, because it
doesn't work well, *at all*.

I am hyper-skeptical to reintroducing them, and *definitely* will veto
reintroducing them on a system which has PNP0B0x devices present.

	-hpa

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[Alessandro Zummo]

On Thu, 19 Dec 2013 06:59:55 -0800
"H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org> wrote:

> EFI time is something we used to support and ripped out, because it
> doesn't work well, *at all*.
> 
> I am hyper-skeptical to reintroducing them, and *definitely* will veto
> reintroducing them on a system which has PNP0B0x devices present.

 Definitely agree.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[joeyli]

於 四，2013-12-19 於 06:59 -0800，H. Peter Anvin 提到：
> On 12/18/2013 11:43 PM, Lee, Chun-Yi wrote:
> > This patchset add the timezone support of ACPI TAD and EFI TIME, it
> > also add codes for adjusting system time base on the timezone value
> > from EFI TIME services when system boot.
> 
> EFI time is something we used to support and ripped out, because it
> doesn't work well, *at all*.
> 
> I am hyper-skeptical to reintroducing them, and *definitely* will veto
> reintroducing them on a system which has PNP0B0x devices present.
> 
> 	-hpa
> 

Then that means the priority of PNP0B0x is higher then "CMOS RTC Not
Present" flag. ACPI spec doesn't have clear definition on this.

I look forward to Borislav's "EFI runtime mapping" to fix the physical
address accessing issue of EFI time service on x86_64 machines. I tested
his patches on a issue machine and it works for walk around BIOS bug.

Can we use EFI time services on x86_64 after Borislav's patches accepted
to mainline?


Thanks a lot!
Joey Lee

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[H. Peter Anvin]

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.

> I look forward to Borislav's "EFI runtime mapping" to fix the physical
> address accessing issue of EFI time service on x86_64 machines. I tested
> his patches on a issue machine and it works for walk around BIOS bug.
> 
> Can we use EFI time services on x86_64 after Borislav's patches accepted
> to mainline?
> 

No.

	-hpa

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[joeyli]

於 四，2013-12-19 於 20:22 -0800，H. Peter Anvin 提到：
> 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.

OK~~

> 
> > I look forward to Borislav's "EFI runtime mapping" to fix the physical
> > address accessing issue of EFI time service on x86_64 machines. I tested
> > his patches on a issue machine and it works for walk around BIOS bug.
> > 
> > Can we use EFI time services on x86_64 after Borislav's patches accepted
> > to mainline?
> > 
> 
> No.
> 
> 	-hpa

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.


Thanks a lot!
Joey Lee

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[H. Peter Anvin]

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.

	-hpa

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[H. Peter Anvin]

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

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[Rafael J. Wysocki]

On Friday, December 20, 2013 01:10:26 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.

My understanding, however, is that to use the TAD, we don't actually need to
create a struct acpi_device for it.  We just need a handle to the ACPICA
object which can be found using acpi_get_devices() as soon as the namespace
has been extracted from the DSDT and friends.  That in turn happens in
acpi_early_init(), which is called from start_kernel() right before
efi_late_init().

Is that early enough?

Rafael

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[H. Peter Anvin]

On 12/20/2013 01:45 PM, Rafael J. Wysocki wrote:
> 
> My understanding, however, is that to use the TAD, we don't actually need to
> create a struct acpi_device for it.  We just need a handle to the ACPICA
> object which can be found using acpi_get_devices() as soon as the namespace
> has been extracted from the DSDT and friends.  That in turn happens in
> acpi_early_init(), which is called from start_kernel() right before
> efi_late_init().
> 
> Is that early enough?
> 

Possibly... will have to investigate.  I would also ask if the same
applies to the PNP0B0x devices -- all we really need there is the
presence/absence indication and the I/O port base.

	-hpa

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[Matt Fleming]

On Fri, 20 Dec, at 01:43:38PM, H. Peter Anvin wrote:
> 
> Possibly... will have to investigate.  I would also ask if the same
> applies to the PNP0B0x devices -- all we really need there is the
> presence/absence indication and the I/O port base.

It's worth noting that efi_late_init() exists solely because the ACPI
infrastructure to find the BGRT table isn't available any earlier.

If we could setup ACPI earlier that would be awesome.

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[Rafael J. Wysocki]

On Friday, December 20, 2013 09:50:56 PM Matt Fleming wrote:
> On Fri, 20 Dec, at 01:43:38PM, H. Peter Anvin wrote:
> > 
> > Possibly... will have to investigate.  I would also ask if the same
> > applies to the PNP0B0x devices -- all we really need there is the
> > presence/absence indication and the I/O port base.
> 
> It's worth noting that efi_late_init() exists solely because the ACPI
> infrastructure to find the BGRT table isn't available any earlier.
> 
> If we could setup ACPI earlier that would be awesome.

I'm not sure 100%, but I *think* we need to do that with interrupts enabled.
At least after mm_init(), because it relies on things initialized there if I
remember correctly.

>From what I can tell at the moment, it might be possible to move it before
efi_enter_virtual_mode() if that would help.

Thanks,
Rafael

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[Matt Fleming]

On Fri, 20 Dec, at 11:18:56PM, Rafael J. Wysocki wrote:
> 
> I'm not sure 100%, but I *think* we need to do that with interrupts enabled.
> At least after mm_init(), because it relies on things initialized there if I
> remember correctly.
> 
> From what I can tell at the moment, it might be possible to move it before
> efi_enter_virtual_mode() if that would help.

Actually yeah, that would be super useful, and I think we'd be able to
get rid of the whole efi_late_init() stuff because we'd no longer need
to hang on to the EFI_BOOT_SERVICES* regions after
SetVirtualAddressMap().

-- 
Matt Fleming, Intel Open Source Technology Center

[RFT][PATCH] ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode() (was: Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME)

[Rafael J. Wysocki]

On Saturday, December 21, 2013 12:21:48 PM Matt Fleming wrote:
> On Fri, 20 Dec, at 11:18:56PM, Rafael J. Wysocki wrote:
> > 
> > I'm not sure 100%, but I *think* we need to do that with interrupts enabled.
> > At least after mm_init(), because it relies on things initialized there if I
> > remember correctly.
> > 
> > From what I can tell at the moment, it might be possible to move it before
> > efi_enter_virtual_mode() if that would help.
> 
> Actually yeah, that would be super useful, and I think we'd be able to
> get rid of the whole efi_late_init() stuff because we'd no longer need
> to hang on to the EFI_BOOT_SERVICES* regions after
> SetVirtualAddressMap().

OK

I don't see any adverse effects of the patch below on a couple of my test
boxes, but (a) they are Intel-based and (b) they are non-EFI, so it would be
good to give it a go on as many machines as reasonably possible.

Thanks,
Rafael

---
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Subject: ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode()

According to Matt Fleming, if acpi_early_init() was executed befpre
efi_enter_virtual_mode(), the EFI initialization could benefit from
it, so make that happen.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 init/main.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-pm/init/main.c
===================================================================
--- linux-pm.orig/init/main.c
+++ linux-pm/init/main.c
@@ -615,6 +615,7 @@ asmlinkage void __init start_kernel(void
 	calibrate_delay();
 	pidmap_init();
 	anon_vma_init();
+	acpi_early_init();
 #ifdef CONFIG_X86
 	if (efi_enabled(EFI_RUNTIME_SERVICES))
 		efi_enter_virtual_mode();
@@ -641,7 +642,6 @@ asmlinkage void __init start_kernel(void
 
 	check_bugs();
 
-	acpi_early_init(); /* before LAPIC and SMP init */
 	sfi_init_late();
 
 	if (efi_enabled(EFI_RUNTIME_SERVICES)) {

Re: [RFT][PATCH] ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode() (was: Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME)

[Borislav Petkov]

On Sun, Jan 12, 2014 at 01:30:23AM +0100, Rafael J. Wysocki wrote:
> I don't see any adverse effects of the patch below on a couple of my test
> boxes, but (a) they are Intel-based and (b) they are non-EFI, so it would be
> good to give it a go on as many machines as reasonably possible.
> 
> Thanks,
> Rafael
> 
> ---
> From: Rafael J. Wysocki <rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Subject: ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode()
> 
> According to Matt Fleming, if acpi_early_init() was executed befpre
> efi_enter_virtual_mode(), the EFI initialization could benefit from
> it, so make that happen.
> 
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> ---
>  init/main.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-pm/init/main.c
> ===================================================================
> --- linux-pm.orig/init/main.c
> +++ linux-pm/init/main.c
> @@ -615,6 +615,7 @@ asmlinkage void __init start_kernel(void
>  	calibrate_delay();
>  	pidmap_init();
>  	anon_vma_init();
> +	acpi_early_init();
>  #ifdef CONFIG_X86
>  	if (efi_enabled(EFI_RUNTIME_SERVICES))
>  		efi_enter_virtual_mode();
> @@ -641,7 +642,6 @@ asmlinkage void __init start_kernel(void
>  
>  	check_bugs();
>  
> -	acpi_early_init(); /* before LAPIC and SMP init */
>  	sfi_init_late();
>  
>  	if (efi_enabled(EFI_RUNTIME_SERVICES)) {
>

Looks good both on kvm+OVMF and on my Dell EFI box.

Tested-by: Borislav Petkov <bp-l3A5Bk7waGM@public.gmane.org>

Toshi has a big EFI box though - if he could run it too, that would be
great :-)

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: [RFT][PATCH] ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode() (was: Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME)

[Toshi Kani]

On Sun, 2014-01-12 at 10:06 +0100, Borislav Petkov wrote:
> On Sun, Jan 12, 2014 at 01:30:23AM +0100, Rafael J. Wysocki wrote:
> > I don't see any adverse effects of the patch below on a couple of my test
> > boxes, but (a) they are Intel-based and (b) they are non-EFI, so it would be
> > good to give it a go on as many machines as reasonably possible.
> > 
> > Thanks,
> > Rafael
> > 
> > ---
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > Subject: ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode()
> > 
> > According to Matt Fleming, if acpi_early_init() was executed befpre
> > efi_enter_virtual_mode(), the EFI initialization could benefit from
> > it, so make that happen.
> > 
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > ---
> >  init/main.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > Index: linux-pm/init/main.c
> > ===================================================================
> > --- linux-pm.orig/init/main.c
> > +++ linux-pm/init/main.c
> > @@ -615,6 +615,7 @@ asmlinkage void __init start_kernel(void
> >  	calibrate_delay();
> >  	pidmap_init();
> >  	anon_vma_init();
> > +	acpi_early_init();
> >  #ifdef CONFIG_X86
> >  	if (efi_enabled(EFI_RUNTIME_SERVICES))
> >  		efi_enter_virtual_mode();
> > @@ -641,7 +642,6 @@ asmlinkage void __init start_kernel(void
> >  
> >  	check_bugs();
> >  
> > -	acpi_early_init(); /* before LAPIC and SMP init */
> >  	sfi_init_late();
> >  
> >  	if (efi_enabled(EFI_RUNTIME_SERVICES)) {
> >
> 
> Looks good both on kvm+OVMF and on my Dell EFI box.
> 
> Tested-by: Borislav Petkov <bp@suse.de>
> 
> Toshi has a big EFI box though - if he could run it too, that would be
> great :-)

Yes, I will test the change.

Thanks,
-Toshi

Re: [RFT][PATCH] ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode() (was: Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME)

[Toshi Kani]

On Mon, 2014-01-13 at 19:04 -0700, Toshi Kani wrote:
> On Sun, 2014-01-12 at 10:06 +0100, Borislav Petkov wrote:
> > On Sun, Jan 12, 2014 at 01:30:23AM +0100, Rafael J. Wysocki wrote:
> > > I don't see any adverse effects of the patch below on a couple of my test
> > > boxes, but (a) they are Intel-based and (b) they are non-EFI, so it would be
> > > good to give it a go on as many machines as reasonably possible.
> > > 
> > > Thanks,
> > > Rafael
> > > 
> > > ---
> > > From: Rafael J. Wysocki <rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > > Subject: ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode()
> > > 
> > > According to Matt Fleming, if acpi_early_init() was executed befpre
> > > efi_enter_virtual_mode(), the EFI initialization could benefit from
> > > it, so make that happen.
> > > 
> > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > > ---
> > >  init/main.c |    2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > Index: linux-pm/init/main.c
> > > ===================================================================
> > > --- linux-pm.orig/init/main.c
> > > +++ linux-pm/init/main.c
> > > @@ -615,6 +615,7 @@ asmlinkage void __init start_kernel(void
> > >  	calibrate_delay();
> > >  	pidmap_init();
> > >  	anon_vma_init();
> > > +	acpi_early_init();
> > >  #ifdef CONFIG_X86
> > >  	if (efi_enabled(EFI_RUNTIME_SERVICES))
> > >  		efi_enter_virtual_mode();
> > > @@ -641,7 +642,6 @@ asmlinkage void __init start_kernel(void
> > >  
> > >  	check_bugs();
> > >  
> > > -	acpi_early_init(); /* before LAPIC and SMP init */
> > >  	sfi_init_late();
> > >  
> > >  	if (efi_enabled(EFI_RUNTIME_SERVICES)) {
> > >
> > 
> > Looks good both on kvm+OVMF and on my Dell EFI box.
> > 
> > Tested-by: Borislav Petkov <bp-l3A5Bk7waGM@public.gmane.org>
> > 
> > Toshi has a big EFI box though - if he could run it too, that would be
> > great :-)
> 
> Yes, I will test the change.

Tested-by: Toshi Kani <toshi.kani-VXdhtT5mjnY@public.gmane.org>

Thanks,
-Toshi

Re: [RFT][PATCH] ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode() (was: Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME)

[Matt Fleming]

On Sun, 12 Jan, at 01:30:23AM, Rafael J. Wysocki wrote:
> On Saturday, December 21, 2013 12:21:48 PM Matt Fleming wrote:
> > On Fri, 20 Dec, at 11:18:56PM, Rafael J. Wysocki wrote:
> > > 
> > > I'm not sure 100%, but I *think* we need to do that with interrupts enabled.
> > > At least after mm_init(), because it relies on things initialized there if I
> > > remember correctly.
> > > 
> > > From what I can tell at the moment, it might be possible to move it before
> > > efi_enter_virtual_mode() if that would help.
> > 
> > Actually yeah, that would be super useful, and I think we'd be able to
> > get rid of the whole efi_late_init() stuff because we'd no longer need
> > to hang on to the EFI_BOOT_SERVICES* regions after
> > SetVirtualAddressMap().
> 
> OK
> 
> I don't see any adverse effects of the patch below on a couple of my test
> boxes, but (a) they are Intel-based and (b) they are non-EFI, so it would be
> good to give it a go on as many machines as reasonably possible.

Thanks Rafael, I'll give this a spin on my test machines here.

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [RFT][PATCH] ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode() (was: Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME)

[Matt Fleming]

On Sun, 12 Jan, at 11:05:46AM, Matt Fleming wrote:
> On Sun, 12 Jan, at 01:30:23AM, Rafael J. Wysocki wrote:
> > On Saturday, December 21, 2013 12:21:48 PM Matt Fleming wrote:
> > > On Fri, 20 Dec, at 11:18:56PM, Rafael J. Wysocki wrote:
> > > > 
> > > > I'm not sure 100%, but I *think* we need to do that with interrupts enabled.
> > > > At least after mm_init(), because it relies on things initialized there if I
> > > > remember correctly.
> > > > 
> > > > From what I can tell at the moment, it might be possible to move it before
> > > > efi_enter_virtual_mode() if that would help.
> > > 
> > > Actually yeah, that would be super useful, and I think we'd be able to
> > > get rid of the whole efi_late_init() stuff because we'd no longer need
> > > to hang on to the EFI_BOOT_SERVICES* regions after
> > > SetVirtualAddressMap().
> > 
> > OK
> > 
> > I don't see any adverse effects of the patch below on a couple of my test
> > boxes, but (a) they are Intel-based and (b) they are non-EFI, so it would be
> > good to give it a go on as many machines as reasonably possible.
> 
> Thanks Rafael, I'll give this a spin on my test machines here.

(Sorry for replying so late)

As various other people have reported, this works fine.

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [RFT][PATCH] ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode() (was: Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME)

[joeyli]

於 日，2014-01-12 於 01:30 +0100，Rafael J. Wysocki 提到：
> OK
> 
> I don't see any adverse effects of the patch below on a couple of my
> test
> boxes, but (a) they are Intel-based and (b) they are non-EFI, so it
> would be
> good to give it a go on as many machines as reasonably possible.
> 
> Thanks,
> Rafael
> 
> ---
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Subject: ACPI / init: Run acpi_early_init() before
> efi_enter_virtual_mode()
> 
> According to Matt Fleming, if acpi_early_init() was executed befpre
> efi_enter_virtual_mode(), the EFI initialization could benefit from
> it, so make that happen.
> 
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>  init/main.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-pm/init/main.c
> ===================================================================
> --- linux-pm.orig/init/main.c
> +++ linux-pm/init/main.c
> @@ -615,6 +615,7 @@ asmlinkage void __init start_kernel(void
>         calibrate_delay();
>         pidmap_init();
>         anon_vma_init();
> +       acpi_early_init();
>  #ifdef CONFIG_X86
>         if (efi_enabled(EFI_RUNTIME_SERVICES))
>                 efi_enter_virtual_mode();
> @@ -641,7 +642,6 @@ asmlinkage void __init start_kernel(void
>  
>         check_bugs();
>  
> -       acpi_early_init(); /* before LAPIC and SMP init */
>         sfi_init_late();
>  
>         if (efi_enabled(EFI_RUNTIME_SERVICES)) {
> 
> 
> 

This patch works to me on Acer Gateway Z5WT2 UEFI notebook and Intel
UEFI development board.

Does it possible move acpi_early_init() to before timekeeping_init()?
The position is also before efi_enter_virtual_mode() and that will be
useful for parsing ACPI TAD to set system clock:

diff --git a/init/main.c b/init/main.c
index febc511..b6d93c8 100644
--- a/init/main.c
+++ b/init/main.c
@@ -565,6 +565,7 @@ asmlinkage void __init start_kernel(void)
        init_timers();
        hrtimers_init();
        softirq_init();
+       acpi_early_init();
        timekeeping_init();
        time_init();
        sched_clock_postinit();
@@ -641,7 +642,6 @@ asmlinkage void __init start_kernel(void)
 
        check_bugs();
 
-       acpi_early_init(); /* before LAPIC and SMP init */
        sfi_init_late();
 
        if (efi_enabled(EFI_RUNTIME_SERVICES)) {


Thanks a lot!
Joey Lee

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFT][PATCH] ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode() (was: Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME)

[Rafael J. Wysocki]

On Tuesday, January 14, 2014 12:09:08 PM joeyli wrote:
> 於 日，2014-01-12 於 01:30 +0100，Rafael J. Wysocki 提到：
> > OK
> > 
> > I don't see any adverse effects of the patch below on a couple of my
> > test
> > boxes, but (a) they are Intel-based and (b) they are non-EFI, so it
> > would be
> > good to give it a go on as many machines as reasonably possible.
> > 
> > Thanks,
> > Rafael
> > 
> > ---
> > From: Rafael J. Wysocki <rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > Subject: ACPI / init: Run acpi_early_init() before
> > efi_enter_virtual_mode()
> > 
> > According to Matt Fleming, if acpi_early_init() was executed befpre
> > efi_enter_virtual_mode(), the EFI initialization could benefit from
> > it, so make that happen.
> > 
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > ---
> >  init/main.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > Index: linux-pm/init/main.c
> > ===================================================================
> > --- linux-pm.orig/init/main.c
> > +++ linux-pm/init/main.c
> > @@ -615,6 +615,7 @@ asmlinkage void __init start_kernel(void
> >         calibrate_delay();
> >         pidmap_init();
> >         anon_vma_init();
> > +       acpi_early_init();
> >  #ifdef CONFIG_X86
> >         if (efi_enabled(EFI_RUNTIME_SERVICES))
> >                 efi_enter_virtual_mode();
> > @@ -641,7 +642,6 @@ asmlinkage void __init start_kernel(void
> >  
> >         check_bugs();
> >  
> > -       acpi_early_init(); /* before LAPIC and SMP init */
> >         sfi_init_late();
> >  
> >         if (efi_enabled(EFI_RUNTIME_SERVICES)) {
> > 
> > 
> > 
> 
> This patch works to me on Acer Gateway Z5WT2 UEFI notebook and Intel
> UEFI development board.
> 
> Does it possible move acpi_early_init() to before timekeeping_init()?

We can do that if it doesn't cause any problems to happen.

Please resubmit your patch with a changelog and we'll ask everyone to try it.

Thanks!

> The position is also before efi_enter_virtual_mode() and that will be
> useful for parsing ACPI TAD to set system clock:
> 
> diff --git a/init/main.c b/init/main.c
> index febc511..b6d93c8 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -565,6 +565,7 @@ asmlinkage void __init start_kernel(void)
>         init_timers();
>         hrtimers_init();
>         softirq_init();
> +       acpi_early_init();
>         timekeeping_init();
>         time_init();
>         sched_clock_postinit();
> @@ -641,7 +642,6 @@ asmlinkage void __init start_kernel(void)
>  
>         check_bugs();
>  
> -       acpi_early_init(); /* before LAPIC and SMP init */
>         sfi_init_late();
>  
>         if (efi_enabled(EFI_RUNTIME_SERVICES)) {
> 
> 
> Thanks a lot!
> Joey Lee
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [RFT][PATCH] ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode()

[H. Peter Anvin]

On 01/13/2014 08:09 PM, joeyli wrote:
> 
> This patch works to me on Acer Gateway Z5WT2 UEFI notebook and Intel
> UEFI development board.
> 
> Does it possible move acpi_early_init() to before timekeeping_init()?
> The position is also before efi_enter_virtual_mode() and that will be
> useful for parsing ACPI TAD to set system clock:
> 
> diff --git a/init/main.c b/init/main.c
> index febc511..b6d93c8 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -565,6 +565,7 @@ asmlinkage void __init start_kernel(void)
>         init_timers();
>         hrtimers_init();
>         softirq_init();
> +       acpi_early_init();
>         timekeeping_init();
>         time_init();
>         sched_clock_postinit();
> @@ -641,7 +642,6 @@ asmlinkage void __init start_kernel(void)
>  
>         check_bugs();
>  
> -       acpi_early_init(); /* before LAPIC and SMP init */
>         sfi_init_late();
>  
>         if (efi_enabled(EFI_RUNTIME_SERVICES)) {
> 

Hi Toshi,

Could you try this variant, too?  If this works as well then we end up
solving two problems in one patch...

	-hpa

Re: [RFT][PATCH] ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode()

[Toshi Kani]

On Tue, 2014-01-14 at 10:00 -0800, H. Peter Anvin wrote:
> On 01/13/2014 08:09 PM, joeyli wrote:
> > 
> > This patch works to me on Acer Gateway Z5WT2 UEFI notebook and Intel
> > UEFI development board.
> > 
> > Does it possible move acpi_early_init() to before timekeeping_init()?
> > The position is also before efi_enter_virtual_mode() and that will be
> > useful for parsing ACPI TAD to set system clock:
> > 
> > diff --git a/init/main.c b/init/main.c
> > index febc511..b6d93c8 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -565,6 +565,7 @@ asmlinkage void __init start_kernel(void)
> >         init_timers();
> >         hrtimers_init();
> >         softirq_init();
> > +       acpi_early_init();
> >         timekeeping_init();
> >         time_init();
> >         sched_clock_postinit();
> > @@ -641,7 +642,6 @@ asmlinkage void __init start_kernel(void)
> >  
> >         check_bugs();
> >  
> > -       acpi_early_init(); /* before LAPIC and SMP init */
> >         sfi_init_late();
> >  
> >         if (efi_enabled(EFI_RUNTIME_SERVICES)) {
> > 
> 
> Hi Toshi,
> 
> Could you try this variant, too?  If this works as well then we end up
> solving two problems in one patch...

Hi Peter,

Yes, this version works fine as well.

Tested-by: Toshi Kani <toshi.kani@hp.com>

Thanks,
-Toshi

Re: [RFT][PATCH] ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode()

[joeyli]

於 二，2014-01-14 於 13:32 -0700，Toshi Kani 提到：
> > > +       acpi_early_init();
> > >         timekeeping_init();
> > >         time_init();
> > >         sched_clock_postinit();
> > > @@ -641,7 +642,6 @@ asmlinkage void __init start_kernel(void)
> > >  
> > >         check_bugs();
> > >  
> > > -       acpi_early_init(); /* before LAPIC and SMP init */
> > >         sfi_init_late();
> > >  
> > >         if (efi_enabled(EFI_RUNTIME_SERVICES)) {
> > > 
> > 
> > Hi Toshi,
> > 
> > Could you try this variant, too?  If this works as well then we end
> up
> > solving two problems in one patch...
> 
> Hi Peter,
> 
> Yes, this version works fine as well.
> 
> Tested-by: Toshi Kani <toshi.kani-VXdhtT5mjnY@public.gmane.org>
> 
> Thanks,
> -Toshi

Thanks a lot for your testing.

I will re-send a formal patch with changelog to everybody.

Regards
Joey Lee

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[joeyli]

於 五，2013-12-20 於 22:45 +0100，Rafael J. Wysocki 提到：
> On Friday, December 20, 2013 01:10:26 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.
> 
> My understanding, however, is that to use the TAD, we don't actually need to
> create a struct acpi_device for it.  We just need a handle to the ACPICA
> object which can be found using acpi_get_devices() as soon as the namespace
> has been extracted from the DSDT and friends.  That in turn happens in
> acpi_early_init(), which is called from start_kernel() right before
> efi_late_init().
> 
> Is that early enough?
> 
> Rafael
> 

Thanks for your good suggestion, then I have a direction on using ACPI
TAD earlier.

Joey Lee

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[Thomas Renninger]

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

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[H. Peter Anvin]

On 12/20/2013 02:53 AM, Thomas Renninger wrote:
> 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?
> 

This is the document... I can't remember who sent me the link to it:

http://goo.gl/R7S9Mk

	-hpa

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[Matthew Garrett]

On Thu, 2013-12-19 at 20:22 -0800, H. Peter Anvin wrote:
> On 12/19/2013 08:05 PM, joeyli wrote:
> > Can we use EFI time services on x86_64 after Borislav's patches accepted
> > to mainline?
> > 
> 
> No.

We will want to use them to (at minimum) obtain the clock timezone.
Using them for general RTC access is less attractive.

-- 
Matthew Garrett <matthew.garrett@nebula.com>

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[H. Peter Anvin]

But we prefer the TAD for that.  The case where the EFI runtime is the only source of that info is problematic as they are known to not work at runtime.  We could collect it at boot and then never change it, although you end up in definitional issues between EFI and the hw RTC.

Matthew Garrett <matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org> wrote:
>On Thu, 2013-12-19 at 20:22 -0800, H. Peter Anvin wrote:
>> On 12/19/2013 08:05 PM, joeyli wrote:
>> > Can we use EFI time services on x86_64 after Borislav's patches
>accepted
>> > to mainline?
>> > 
>> 
>> No.
>
>We will want to use them to (at minimum) obtain the clock timezone.
>Using them for general RTC access is less attractive.

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[Matthew Garrett]

On Fri, 2013-12-20 at 08:57 -0800, H. Peter Anvin wrote:
> But we prefer the TAD for that.  The case where the EFI runtime is the only source of that info is problematic as they are known to not work at runtime.  We could collect it at boot and then never change it, although you end up in definitional issues between EFI and the hw RTC.

Most shipping UEFI hardware has no TAD.

-- 
Matthew Garrett <matthew.garrett@nebula.com>

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[H. Peter Anvin]

Yes, but the TZ isn't all that critical, either.  It certainly doesn't matter at all for a pure Linux system.

Matthew Garrett <matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org> wrote:
>On Fri, 2013-12-20 at 08:57 -0800, H. Peter Anvin wrote:
>> But we prefer the TAD for that.  The case where the EFI runtime is
>the only source of that info is problematic as they are known to not
>work at runtime.  We could collect it at boot and then never change it,
>although you end up in definitional issues between EFI and the hw RTC.
>
>Most shipping UEFI hardware has no TAD.

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[Matthew Garrett]

On Fri, 2013-12-20 at 12:29 -0800, H. Peter Anvin wrote:
> Yes, but the TZ isn't all that critical, either.  It certainly doesn't matter at all for a pure Linux system.

No, but it does matter for a great number of deployed Linux systems.
Dealing with the timezone over DST changes has been a perpetual problem,
and if we can make that work then life will be significantly better.

-- 
Matthew Garrett <matthew.garrett@nebula.com>

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[H. Peter Anvin]

On 12/20/2013 12:32 PM, Matthew Garrett wrote:
> On Fri, 2013-12-20 at 12:29 -0800, H. Peter Anvin wrote:
>> Yes, but the TZ isn't all that critical, either.  It certainly doesn't matter at all for a pure Linux system.
> 
> No, but it does matter for a great number of deployed Linux systems.
> Dealing with the timezone over DST changes has been a perpetual problem,
> and if we can make that work then life will be significantly better.
> 

And as I pointed out, it can matter a lot for VMs, since the provider
doesn't want to provision the VMs differently for different types of guests.

	-hpa

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[H. Peter Anvin]

On 12/20/2013 07:16 AM, Matthew Garrett wrote:
> On Thu, 2013-12-19 at 20:22 -0800, H. Peter Anvin wrote:
>> On 12/19/2013 08:05 PM, joeyli wrote:
>>> Can we use EFI time services on x86_64 after Borislav's patches accepted
>>> to mainline?
>>>
>>
>> No.
> 
> We will want to use them to (at minimum) obtain the clock timezone.
> Using them for general RTC access is less attractive.
> 

One option is to use the EFI runtime call to get and save the clock
timezone before we call ExitBootServices() in the EFI stub.  This
doesn't obviate the need for proper handling of the TAD, though,
especially since it is likely that future hardware will not have a RTC
in the current form (it is a way more complex device than is needed,
which wouldn't normally be a problem, but the fact that it has to
operate in the Vbat well makes it a major one.)

	-hpa

[RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[Lee, Chun-Yi]

This patchset add the timezone support of ACPI TAD and EFI TIME, it
also add codes for adjusting system time base on the timezone value
from EFI TIME services when system boot.

Those patches bring the following changes:

 + Add ACPI driver against ACPI000E ACPI Time and Alarm Device.

 + Add RTC driver of ACPI TAD.

 + Add rtc ioctl functions, RTC_RD_GMTOFF and RTC_SET_GMTOFF, provide
   interface to user space for maintain timezone value in BIOS.
   The GMTOFF names of ioctl functions match with the tm_gmtoff field
   in rtc_time and tm structure in GNU C library.

 + Add rtc ioctl function, RTC_CAPS_READ, provide to user space for
   grab the capabilities value to timezone and daylight of interface.

 + Moved duplicate functions to efi.h header for convert EFI Time.

 + When "CMOS RTC not Present" flag set in FADT, block CMOS RTC interface
   and switch to EFI time services.

 + Adjusting system time base on timezone from EFI time when system boot.

 + Add rtc-tz.txt document.

Please set CONFIG_RTC_DRV_EFI=m and CONFIG_RTC_ACPI_TAD=m to build RTC ACPI
TAD and EFI TIME drivers.For testing, please use "acpi_no_cmos_rtc=1" to set
CMOST RTC not Present flag in FADT to trigger the mechanism for adjust system
time and block CMOS interface.

About the definition of timezone and the format transformation between ACPI,
EFI and tm_gmtoff of GNU. Please check the rtc-tz.txt document in patch.


Jan Beulich (1):
  x86-64/efi: Use EFI to deal with platform wall clock (again)

Lee, Chun-Yi (13):
  rtc-efi: fix decrease day twice when computing year days
  rtc: block registration of rtc-cmos when CMOS RTC Not Present
  ACPI: Add ACPI 5.0 Time and Alarm Device driver
  rtc: Add RTC driver of ACPI Time and Alarm Device
  rtc-efi: register rtc-efi device when EFI enabled
  rtc-efi: add GMTOFF support to rtc_efi
  rtc-efi: set uie_unsupported for indicate rtc-efi doesn't support UIE
  efi: move functions of access efi time to header file for sharing
  rtc: improve and move week day computing function to rtc header
  rtc: switch to get/set rtc time to efi functions if CMOS RTC Not
  efi: adjust system time base on timezone from EFI time services
  Documentation/RTC: add document of ACPI TAD and EFI TIME driver
  acpi: add early parameter to set CMOS RTC Not Present bit for testing

 Documentation/rtc-tz.txt    |  510 +++++++++++++++++++++++++++++++++++++++++++
 arch/x86/kernel/acpi/boot.c |   17 ++
 arch/x86/kernel/rtc.c       |   28 ++-
 arch/x86/mm/pageattr.c      |   10 +-
 arch/x86/platform/efi/efi.c |   89 ++++++--
 drivers/acpi/Makefile       |    3 +
 drivers/acpi/acpi_tad.c     |  176 +++++++++++++++
 drivers/acpi/bus.c          |    3 +
 drivers/acpi/internal.h     |    5 +
 drivers/char/efirtc.c       |   98 ---------
 drivers/rtc/Kconfig         |   12 +-
 drivers/rtc/Makefile        |    1 +
 drivers/rtc/rtc-acpitad.c   |  283 ++++++++++++++++++++++++
 drivers/rtc/rtc-cmos.c      |    9 +
 drivers/rtc/rtc-dev.c       |    4 +
 drivers/rtc/rtc-efi.c       |  177 +++++++---------
 drivers/rtc/rtc-sysfs.c     |    8 +
 include/asm-generic/rtc.h   |   22 ++
 include/linux/acpi.h        |   31 +++
 include/linux/efi.h         |  127 +++++++++++-
 include/linux/rtc.h         |   43 ++++
 include/uapi/linux/rtc.h    |    5 +
 init/main.c                 |   13 +-
 kernel/time.c               |    2 +-
 24 files changed, 1439 insertions(+), 237 deletions(-)
 create mode 100644 Documentation/rtc-tz.txt
 create mode 100644 drivers/acpi/acpi_tad.c
 create mode 100644 drivers/rtc/rtc-acpitad.c