[PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[Lee, Chun-Yi]

UEFI time services, GetTime(), SetTime(), GetWakeupTime(), SetWakeupTime() are also
supported by other non-IA64 architecutre with UEFI BIOS, e.g. x86.

This patch changed RTC_DRV_EFI configuration to depend on EFI but not just IA64. It
checks efi_enabled flag and efi-rtc driver should enabled.

Cc: Matt Fleming <matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: H. Peter Anvin <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
Cc: Matthew Garrett <matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>
Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Cc: Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Jan Beulich <JBeulich-IBi9RG/b67k@public.gmane.org>
Signed-off-by: Lee, Chun-Yi <jlee-IBi9RG/b67k@public.gmane.org>
---
 arch/x86/platform/efi/efi.c |   20 ++++++++++++++++++++
 drivers/rtc/Kconfig         |    2 +-
 2 files changed, 21 insertions(+), 1 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index ad44391..f08d28b 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -41,6 +41,9 @@
 #include <linux/io.h>
 #include <linux/reboot.h>
 #include <linux/bcd.h>
+#if (defined CONFIG_RTC_DRV_EFI || defined CONFIG_RTC_DRV_EFI_MODULE)
+#include <linux/platform_device.h>
+#endif
 
 #include <asm/setup.h>
 #include <asm/efi.h>
@@ -961,6 +964,23 @@ void __init efi_enter_virtual_mode(void)
 	kfree(new_memmap);
 }
 
+#if (defined CONFIG_RTC_DRV_EFI || defined CONFIG_RTC_DRV_EFI_MODULE)
+static struct platform_device rtc_efi_dev = {
+	.name = "rtc-efi",
+	.id = -1,
+};
+
+static int __init rtc_init(void)
+{
+	if (efi_enabled && platform_device_register(&rtc_efi_dev) < 0)
+		pr_err("unable to register rtc-efi device...\n");
+
+	/* not necessarily an error */
+	return 0;
+}
+arch_initcall(rtc_init);
+#endif
+
 /*
  * Convenience functions to obtain memory types and attributes
  */
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index d0cea02..7796f0a 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -621,7 +621,7 @@ config RTC_DRV_DA9055
 
 config RTC_DRV_EFI
 	tristate "EFI RTC"
-	depends on IA64
+	depends on EFI
 	help
 	  If you say yes here you will get support for the EFI
 	  Real Time Clock.
-- 
1.6.4.2

[PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[Lee, Chun-Yi]

UEFI time services, GetTime(), SetTime(), GetWakeupTime(), SetWakeupTime() are also
supported by other non-IA64 architecutre with UEFI BIOS, e.g. x86.

This patch changed RTC_DRV_EFI configuration to depend on EFI but not just IA64. It
checks efi_enabled flag and efi-rtc driver should enabled.

Cc: Matt Fleming <matt.fleming@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Matthew Garrett <matthew.garrett@nebula.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
---
 arch/x86/platform/efi/efi.c |   20 ++++++++++++++++++++
 drivers/rtc/Kconfig         |    2 +-
 2 files changed, 21 insertions(+), 1 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index ad44391..f08d28b 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -41,6 +41,9 @@
 #include <linux/io.h>
 #include <linux/reboot.h>
 #include <linux/bcd.h>
+#if (defined CONFIG_RTC_DRV_EFI || defined CONFIG_RTC_DRV_EFI_MODULE)
+#include <linux/platform_device.h>
+#endif
 
 #include <asm/setup.h>
 #include <asm/efi.h>
@@ -961,6 +964,23 @@ void __init efi_enter_virtual_mode(void)
 	kfree(new_memmap);
 }
 
+#if (defined CONFIG_RTC_DRV_EFI || defined CONFIG_RTC_DRV_EFI_MODULE)
+static struct platform_device rtc_efi_dev = {
+	.name = "rtc-efi",
+	.id = -1,
+};
+
+static int __init rtc_init(void)
+{
+	if (efi_enabled && platform_device_register(&rtc_efi_dev) < 0)
+		pr_err("unable to register rtc-efi device...\n");
+
+	/* not necessarily an error */
+	return 0;
+}
+arch_initcall(rtc_init);
+#endif
+
 /*
  * Convenience functions to obtain memory types and attributes
  */
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index d0cea02..7796f0a 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -621,7 +621,7 @@ config RTC_DRV_DA9055
 
 config RTC_DRV_EFI
 	tristate "EFI RTC"
-	depends on IA64
+	depends on EFI
 	help
 	  If you say yes here you will get support for the EFI
 	  Real Time Clock.
-- 
1.6.4.2

[PATCH 2/3] rtc-efi: add timezone to rtc_time that will used by rtc-efi

[Lee, Chun-Yi]

Per UEFI 2.3.1 spec, we can use SetTime() to store the timezone value to BIOS and 
get it back by GetTime(). It's good for installation system to gain the default 
timezone setting from BIOS that was set by manufacturer. 

This patch adds new field tm_timezone to rtc_time struct for expose the timezone
to userspace. And, patch also adds the check logic to rtc-efi when convert timezone.
The check logic of timezone only affect on x86 architecture and keep the original
EFI_UNSPECIFIED_TIMEZONE value on IA64.

Cc: Matt Fleming <matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: H. Peter Anvin <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
Cc: Matthew Garrett <matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>
Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Cc: Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Jan Beulich <JBeulich-IBi9RG/b67k@public.gmane.org>
Signed-off-by: Lee, Chun-Yi <jlee-IBi9RG/b67k@public.gmane.org>
---
 drivers/rtc/rtc-efi.c    |   20 +++++++++++++++++---
 include/uapi/linux/rtc.h |    1 +
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/rtc-efi.c b/drivers/rtc/rtc-efi.c
index c9f890b..4e74ec0 100644
--- a/drivers/rtc/rtc-efi.c
+++ b/drivers/rtc/rtc-efi.c
@@ -62,7 +62,7 @@ compute_wday(efi_time_t *eft)
 	return (ndays + 4) % 7;
 }
 
-static void
+static int
 convert_to_efi_time(struct rtc_time *wtime, efi_time_t *eft)
 {
 	eft->year	= wtime->tm_year + 1900;
@@ -73,7 +73,16 @@ convert_to_efi_time(struct rtc_time *wtime, efi_time_t *eft)
 	eft->second 	= wtime->tm_sec;
 	eft->nanosecond = 0;
 	eft->daylight	= wtime->tm_isdst ? EFI_ISDST : 0;
+#ifdef CONFIG_X86
+	if (abs(wtime->tm_timezone) > 1440 &&
+			wtime->tm_timezone != EFI_UNSPECIFIED_TIMEZONE)
+		return -EINVAL;
+	eft->timezone	= wtime->tm_timezone;
+#else
 	eft->timezone	= EFI_UNSPECIFIED_TIMEZONE;
+#endif /* CONFIG_X86 */
+
+	return 0;
 }
 
 static void
@@ -86,6 +95,9 @@ convert_from_efi_time(efi_time_t *eft, struct rtc_time *wtime)
 	wtime->tm_mday = eft->day;
 	wtime->tm_mon  = eft->month - 1;
 	wtime->tm_year = eft->year - 1900;
+#ifdef CONFIG_X86
+	wtime->tm_timezone = eft->timezone;
+#endif /* CONFIG_X86 */
 
 	/* day of the week [0-6], Sunday=0 */
 	wtime->tm_wday = compute_wday(eft);
@@ -130,7 +142,8 @@ static int efi_set_alarm(struct device *dev, struct rtc_wkalrm *wkalrm)
 	efi_time_t eft;
 	efi_status_t status;
 
-	convert_to_efi_time(&wkalrm->time, &eft);
+	if (convert_to_efi_time(&wkalrm->time, &eft))
+		return -EINVAL;
 
 	/*
 	 * XXX Fixme:
@@ -171,7 +184,8 @@ static int efi_set_time(struct device *dev, struct rtc_time *tm)
 	efi_status_t status;
 	efi_time_t eft;
 
-	convert_to_efi_time(tm, &eft);
+	if (convert_to_efi_time(tm, &eft))
+		return -EINVAL;
 
 	status = efi.set_time(&eft);
 
diff --git a/include/uapi/linux/rtc.h b/include/uapi/linux/rtc.h
index f8c82e6..841725f 100644
--- a/include/uapi/linux/rtc.h
+++ b/include/uapi/linux/rtc.h
@@ -27,6 +27,7 @@ struct rtc_time {
 	int tm_wday;
 	int tm_yday;
 	int tm_isdst;
+	int tm_timezone;
 };
 
 /*
-- 
1.6.4.2

[PATCH 2/3] rtc-efi: add timezone to rtc_time that will used by rtc-efi

[Lee, Chun-Yi]

Per UEFI 2.3.1 spec, we can use SetTime() to store the timezone value to BIOS and 
get it back by GetTime(). It's good for installation system to gain the default 
timezone setting from BIOS that was set by manufacturer. 

This patch adds new field tm_timezone to rtc_time struct for expose the timezone
to userspace. And, patch also adds the check logic to rtc-efi when convert timezone.
The check logic of timezone only affect on x86 architecture and keep the original
EFI_UNSPECIFIED_TIMEZONE value on IA64.

Cc: Matt Fleming <matt.fleming@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Matthew Garrett <matthew.garrett@nebula.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
---
 drivers/rtc/rtc-efi.c    |   20 +++++++++++++++++---
 include/uapi/linux/rtc.h |    1 +
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/rtc-efi.c b/drivers/rtc/rtc-efi.c
index c9f890b..4e74ec0 100644
--- a/drivers/rtc/rtc-efi.c
+++ b/drivers/rtc/rtc-efi.c
@@ -62,7 +62,7 @@ compute_wday(efi_time_t *eft)
 	return (ndays + 4) % 7;
 }
 
-static void
+static int
 convert_to_efi_time(struct rtc_time *wtime, efi_time_t *eft)
 {
 	eft->year	= wtime->tm_year + 1900;
@@ -73,7 +73,16 @@ convert_to_efi_time(struct rtc_time *wtime, efi_time_t *eft)
 	eft->second 	= wtime->tm_sec;
 	eft->nanosecond = 0;
 	eft->daylight	= wtime->tm_isdst ? EFI_ISDST : 0;
+#ifdef CONFIG_X86
+	if (abs(wtime->tm_timezone) > 1440 &&
+			wtime->tm_timezone != EFI_UNSPECIFIED_TIMEZONE)
+		return -EINVAL;
+	eft->timezone	= wtime->tm_timezone;
+#else
 	eft->timezone	= EFI_UNSPECIFIED_TIMEZONE;
+#endif /* CONFIG_X86 */
+
+	return 0;
 }
 
 static void
@@ -86,6 +95,9 @@ convert_from_efi_time(efi_time_t *eft, struct rtc_time *wtime)
 	wtime->tm_mday = eft->day;
 	wtime->tm_mon  = eft->month - 1;
 	wtime->tm_year = eft->year - 1900;
+#ifdef CONFIG_X86
+	wtime->tm_timezone = eft->timezone;
+#endif /* CONFIG_X86 */
 
 	/* day of the week [0-6], Sunday=0 */
 	wtime->tm_wday = compute_wday(eft);
@@ -130,7 +142,8 @@ static int efi_set_alarm(struct device *dev, struct rtc_wkalrm *wkalrm)
 	efi_time_t eft;
 	efi_status_t status;
 
-	convert_to_efi_time(&wkalrm->time, &eft);
+	if (convert_to_efi_time(&wkalrm->time, &eft))
+		return -EINVAL;
 
 	/*
 	 * XXX Fixme:
@@ -171,7 +184,8 @@ static int efi_set_time(struct device *dev, struct rtc_time *tm)
 	efi_status_t status;
 	efi_time_t eft;
 
-	convert_to_efi_time(tm, &eft);
+	if (convert_to_efi_time(tm, &eft))
+		return -EINVAL;
 
 	status = efi.set_time(&eft);
 
diff --git a/include/uapi/linux/rtc.h b/include/uapi/linux/rtc.h
index f8c82e6..841725f 100644
--- a/include/uapi/linux/rtc.h
+++ b/include/uapi/linux/rtc.h
@@ -27,6 +27,7 @@ struct rtc_time {
 	int tm_wday;
 	int tm_yday;
 	int tm_isdst;
+	int tm_timezone;
 };
 
 /*
-- 
1.6.4.2

[PATCH 3/3] rtc-efi: set uie_unsupported for indicate rtc-efi doesn't support UIE mode

[Lee, Chun-Yi]

This patch set uie_unsupported flag when driver probed because current rtc-efi
driver doesn't support UIE mode. Otherwise RTC_UIE_ON ioctl doesn't return EINVAL
and it causes userspace think the RTC_UIE supported by rtc-efi.

Set uie_unsupported then We can enable CONFIG_RTC_INTF_DEV_UIE_EMUL to emulate
RTC_UIE on rtc-efi.

Cc: Matt Fleming <matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: H. Peter Anvin <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
Cc: Matthew Garrett <matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>
Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Cc: Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Jan Beulich <JBeulich-IBi9RG/b67k@public.gmane.org>
Signed-off-by: Lee, Chun-Yi <jlee-IBi9RG/b67k@public.gmane.org>
---
 drivers/rtc/rtc-efi.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/rtc/rtc-efi.c b/drivers/rtc/rtc-efi.c
index 4e74ec0..dad1687 100644
--- a/drivers/rtc/rtc-efi.c
+++ b/drivers/rtc/rtc-efi.c
@@ -208,6 +208,8 @@ static int __init efi_rtc_probe(struct platform_device *dev)
 	if (IS_ERR(rtc))
 		return PTR_ERR(rtc);
 
+	rtc->uie_unsupported = 1;
+
 	platform_set_drvdata(dev, rtc);
 
 	return 0;
-- 
1.6.4.2

[PATCH 3/3] rtc-efi: set uie_unsupported for indicate rtc-efi doesn't support UIE mode

[Lee, Chun-Yi]

This patch set uie_unsupported flag when driver probed because current rtc-efi
driver doesn't support UIE mode. Otherwise RTC_UIE_ON ioctl doesn't return EINVAL
and it causes userspace think the RTC_UIE supported by rtc-efi.

Set uie_unsupported then We can enable CONFIG_RTC_INTF_DEV_UIE_EMUL to emulate
RTC_UIE on rtc-efi.

Cc: Matt Fleming <matt.fleming@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Matthew Garrett <matthew.garrett@nebula.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
---
 drivers/rtc/rtc-efi.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/rtc/rtc-efi.c b/drivers/rtc/rtc-efi.c
index 4e74ec0..dad1687 100644
--- a/drivers/rtc/rtc-efi.c
+++ b/drivers/rtc/rtc-efi.c
@@ -208,6 +208,8 @@ static int __init efi_rtc_probe(struct platform_device *dev)
 	if (IS_ERR(rtc))
 		return PTR_ERR(rtc);
 
+	rtc->uie_unsupported = 1;
+
 	platform_set_drvdata(dev, rtc);
 
 	return 0;
-- 
1.6.4.2

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[Matthew Garrett]

On Sat, 2012-12-29 at 00:26 +0800, Lee, Chun-Yi wrote:
> UEFI time services, GetTime(), SetTime(), GetWakeupTime(), SetWakeupTime() are also
> supported by other non-IA64 architecutre with UEFI BIOS, e.g. x86.
> 
> This patch changed RTC_DRV_EFI configuration to depend on EFI but not just IA64. It
> checks efi_enabled flag and efi-rtc driver should enabled.

In theory, certainly - but do we still have machines that explode if the
get_time call is made? We may also want to think about disabling the
legacy access to the RTC if the EFI calls are present.

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[Matthew Garrett]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 718 bytes --]

On Sat, 2012-12-29 at 00:26 +0800, Lee, Chun-Yi wrote:
> UEFI time services, GetTime(), SetTime(), GetWakeupTime(), SetWakeupTime() are also
> supported by other non-IA64 architecutre with UEFI BIOS, e.g. x86.
> 
> This patch changed RTC_DRV_EFI configuration to depend on EFI but not just IA64. It
> checks efi_enabled flag and efi-rtc driver should enabled.

In theory, certainly - but do we still have machines that explode if the
get_time call is made? We may also want to think about disabling the
legacy access to the RTC if the EFI calls are present.
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[H. Peter Anvin]

We do have such machines, which is why this change has been reverted twice already.  I believe we should stick to the priority scheme I proposed a few weeks ago.

Matthew Garrett <matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org> wrote:

>On Sat, 2012-12-29 at 00:26 +0800, Lee, Chun-Yi wrote:
>> UEFI time services, GetTime(), SetTime(), GetWakeupTime(),
>SetWakeupTime() are also
>> supported by other non-IA64 architecutre with UEFI BIOS, e.g. x86.
>> 
>> This patch changed RTC_DRV_EFI configuration to depend on EFI but not
>just IA64. It
>> checks efi_enabled flag and efi-rtc driver should enabled.
>
>In theory, certainly - but do we still have machines that explode if
>the
>get_time call is made? We may also want to think about disabling the
>legacy access to the RTC if the EFI calls are present.

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

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[H. Peter Anvin]

We do have such machines, which is why this change has been reverted twice already.  I believe we should stick to the priority scheme I proposed a few weeks ago.

Matthew Garrett <matthew.garrett@nebula.com> wrote:

>On Sat, 2012-12-29 at 00:26 +0800, Lee, Chun-Yi wrote:
>> UEFI time services, GetTime(), SetTime(), GetWakeupTime(),
>SetWakeupTime() are also
>> supported by other non-IA64 architecutre with UEFI BIOS, e.g. x86.
>> 
>> This patch changed RTC_DRV_EFI configuration to depend on EFI but not
>just IA64. It
>> checks efi_enabled flag and efi-rtc driver should enabled.
>
>In theory, certainly - but do we still have machines that explode if
>the
>get_time call is made? We may also want to think about disabling the
>legacy access to the RTC if the EFI calls are present.

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

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[Matthew Garrett]

On Fri, 2012-12-28 at 11:07 -0800, H. Peter Anvin wrote:
> We do have such machines, which is why this change has been reverted twice already.  I believe we should stick to the priority scheme I proposed a few weeks ago.

I seem to have missed that discussion, and couldn't find it after a
brief search. Got a pointer?

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[Matthew Garrett]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 479 bytes --]

On Fri, 2012-12-28 at 11:07 -0800, H. Peter Anvin wrote:
> We do have such machines, which is why this change has been reverted twice already.  I believe we should stick to the priority scheme I proposed a few weeks ago.

I seem to have missed that discussion, and couldn't find it after a
brief search. Got a pointer?
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[H. Peter Anvin]

On 12/28/2012 11:17 AM, Matthew Garrett wrote:
> On Fri, 2012-12-28 at 11:07 -0800, H. Peter Anvin wrote:
>> We do have such machines, which is why this change has been reverted twice already.  I believe we should stick to the priority scheme I proposed a few weeks ago.
>
> I seem to have missed that discussion, and couldn't find it after a
> brief search. Got a pointer?
>

Looks like it was a non-public distribution ... anyway, what I wrote was:

> 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.
>
> I'm unsure what the ordering of 1 & 2 should be.  The ACPI device has
> the advantage that it contains time zone information, which is important
> for Windows interoperability, and at least optionally supports
> millisecond resolution; there is no way to even export "this is where
> you find time zone information" (since we're dealing with an RTC with
> embedded CMOS, there is storage available, it is just a matter of
> telling the OS how to find it) for the PNP0B0x devices.
>
> The TAD is also guaranteed to map 1:1 to the EFI RTC.
>
> 	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[H. Peter Anvin]

On 12/28/2012 11:17 AM, Matthew Garrett wrote:
> On Fri, 2012-12-28 at 11:07 -0800, H. Peter Anvin wrote:
>> We do have such machines, which is why this change has been reverted twice already.  I believe we should stick to the priority scheme I proposed a few weeks ago.
>
> I seem to have missed that discussion, and couldn't find it after a
> brief search. Got a pointer?
>

Looks like it was a non-public distribution ... anyway, what I wrote was:

> 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.
>
> I'm unsure what the ordering of 1 & 2 should be.  The ACPI device has
> the advantage that it contains time zone information, which is important
> for Windows interoperability, and at least optionally supports
> millisecond resolution; there is no way to even export "this is where
> you find time zone information" (since we're dealing with an RTC with
> embedded CMOS, there is storage available, it is just a matter of
> telling the OS how to find it) for the PNP0B0x devices.
>
> The TAD is also guaranteed to map 1:1 to the EFI RTC.
>
> 	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[Matthew Garrett]

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.

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[Matthew Garrett]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 894 bytes --]

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.
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[Matthew Garrett]

On Fri, 2012-12-28 at 15:32 -0800, H. Peter Anvin wrote:
> No, that is explicitly the ordering that is excludable.

Windows uses the UEFI time functions. The fact that they fail for us on
a bunch of systems is just another symptom of our general failure to
accurately mimic Windows when making runtime calls, and we should just
make sure that that gets fixed rather than layering more workarounds on
top. It's an embarrassment that we're still unable to deal with
platforms that work fine with another OS. 

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[Matthew Garrett]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 667 bytes --]

On Fri, 2012-12-28 at 15:32 -0800, H. Peter Anvin wrote:
> No, that is explicitly the ordering that is excludable.

Windows uses the UEFI time functions. The fact that they fail for us on
a bunch of systems is just another symptom of our general failure to
accurately mimic Windows when making runtime calls, and we should just
make sure that that gets fixed rather than layering more workarounds on
top. It's an embarrassment that we're still unable to deal with
platforms that work fine with another OS. 
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[H. Peter Anvin]

On 12/28/2012 03:39 PM, Matthew Garrett wrote:
> On Fri, 2012-12-28 at 15:32 -0800, H. Peter Anvin wrote:
>> No, that is explicitly the ordering that is excludable.
> 
> Windows uses the UEFI time functions. The fact that they fail for us on
> a bunch of systems is just another symptom of our general failure to
> accurately mimic Windows when making runtime calls, and we should just
> make sure that that gets fixed rather than layering more workarounds on
> top. It's an embarrassment that we're still unable to deal with
> platforms that work fine with another OS. 
> 

Are they using them in preference to ACPI?  This seems a bit odd, since
one can presume that the ACPI functions were added at Microsoft's request...

	-hpa

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[Matthew Garrett]

On Fri, 2012-12-28 at 16:42 -0800, H. Peter Anvin wrote:
> On 12/28/2012 03:39 PM, Matthew Garrett wrote:
> > On Fri, 2012-12-28 at 15:32 -0800, H. Peter Anvin wrote:
> >> No, that is explicitly the ordering that is excludable.
> > 
> > Windows uses the UEFI time functions. The fact that they fail for us on
> > a bunch of systems is just another symptom of our general failure to
> > accurately mimic Windows when making runtime calls, and we should just
> > make sure that that gets fixed rather than layering more workarounds on
> > top. It's an embarrassment that we're still unable to deal with
> > platforms that work fine with another OS. 
> > 
> 
> Are they using them in preference to ACPI?  This seems a bit odd, since
> one can presume that the ACPI functions were added at Microsoft's request...

In preference to the ACPI RTC, I haven't yet had an ACPI 5.0 TAD device
to test in comparison.

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[Matthew Garrett]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1065 bytes --]

On Fri, 2012-12-28 at 16:42 -0800, H. Peter Anvin wrote:
> On 12/28/2012 03:39 PM, Matthew Garrett wrote:
> > On Fri, 2012-12-28 at 15:32 -0800, H. Peter Anvin wrote:
> >> No, that is explicitly the ordering that is excludable.
> > 
> > Windows uses the UEFI time functions. The fact that they fail for us on
> > a bunch of systems is just another symptom of our general failure to
> > accurately mimic Windows when making runtime calls, and we should just
> > make sure that that gets fixed rather than layering more workarounds on
> > top. It's an embarrassment that we're still unable to deal with
> > platforms that work fine with another OS. 
> > 
> 
> Are they using them in preference to ACPI?  This seems a bit odd, since
> one can presume that the ACPI functions were added at Microsoft's request...

In preference to the ACPI RTC, I haven't yet had an ACPI 5.0 TAD device
to test in comparison.
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[H. Peter Anvin]

Again, we could hack a simulator and try it.

Matthew Garrett <matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org> wrote:

>On Fri, 2012-12-28 at 16:42 -0800, H. Peter Anvin wrote:
>> On 12/28/2012 03:39 PM, Matthew Garrett wrote:
>> > On Fri, 2012-12-28 at 15:32 -0800, H. Peter Anvin wrote:
>> >> No, that is explicitly the ordering that is excludable.
>> > 
>> > Windows uses the UEFI time functions. The fact that they fail for
>us on
>> > a bunch of systems is just another symptom of our general failure
>to
>> > accurately mimic Windows when making runtime calls, and we should
>just
>> > make sure that that gets fixed rather than layering more
>workarounds on
>> > top. It's an embarrassment that we're still unable to deal with
>> > platforms that work fine with another OS. 
>> > 
>> 
>> Are they using them in preference to ACPI?  This seems a bit odd,
>since
>> one can presume that the ACPI functions were added at Microsoft's
>request...
>
>In preference to the ACPI RTC, I haven't yet had an ACPI 5.0 TAD device
>to test in comparison.

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

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[H. Peter Anvin]

Again, we could hack a simulator and try it.

Matthew Garrett <matthew.garrett@nebula.com> wrote:

>On Fri, 2012-12-28 at 16:42 -0800, H. Peter Anvin wrote:
>> On 12/28/2012 03:39 PM, Matthew Garrett wrote:
>> > On Fri, 2012-12-28 at 15:32 -0800, H. Peter Anvin wrote:
>> >> No, that is explicitly the ordering that is excludable.
>> > 
>> > Windows uses the UEFI time functions. The fact that they fail for
>us on
>> > a bunch of systems is just another symptom of our general failure
>to
>> > accurately mimic Windows when making runtime calls, and we should
>just
>> > make sure that that gets fixed rather than layering more
>workarounds on
>> > top. It's an embarrassment that we're still unable to deal with
>> > platforms that work fine with another OS. 
>> > 
>> 
>> Are they using them in preference to ACPI?  This seems a bit odd,
>since
>> one can presume that the ACPI functions were added at Microsoft's
>request...
>
>In preference to the ACPI RTC, I haven't yet had an ACPI 5.0 TAD device
>to test in comparison.

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

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[Matthew Garrett]

On Fri, 2012-12-28 at 21:19 -0800, H. Peter Anvin wrote:
> Again, we could hack a simulator and try it.

Yeah, shouldn't be too hard to wedge into qemu/ovmf.

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[Matthew Garrett]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 318 bytes --]

On Fri, 2012-12-28 at 21:19 -0800, H. Peter Anvin wrote:
> Again, we could hack a simulator and try it.

Yeah, shouldn't be too hard to wedge into qemu/ovmf.
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[H. Peter Anvin]

On 12/28/2012 12:49 PM, Matthew Garrett wrote:
> 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.
> 

[Resending due to misconfigured tablet]

3 before 2 is exactly what is known to break on existing hardware (ASUS).

If anything, we should move to using the EFI RTC as a very last resort,
i.e. 3 after 4.  Ideally we should match Win8 behavior, but that would
require someone mocking up different ACPI and EFI functions in a
simulator and see how Win8 prioritizes things.

	-hpa

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[H. Peter Anvin]

On 12/28/2012 12:49 PM, Matthew Garrett wrote:
> 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.
> 

[Resending due to misconfigured tablet]

3 before 2 is exactly what is known to break on existing hardware (ASUS).

If anything, we should move to using the EFI RTC as a very last resort,
i.e. 3 after 4.  Ideally we should match Win8 behavior, but that would
require someone mocking up different ACPI and EFI functions in a
simulator and see how Win8 prioritizes things.

	-hpa

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[joeyli]

Hi hpa,  

於 五，2012-12-28 於 15:44 -0800，H. Peter Anvin 提到：
> On 12/28/2012 12:49 PM, Matthew Garrett wrote:
> > 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.
> > 
> 
> [Resending due to misconfigured tablet]
> 
> 3 before 2 is exactly what is known to break on existing hardware (ASUS).

I didn't find the EFI RTC problem on Asus from google. 
Could you please share what's the situation on ASUS hardware?


Thanks a lot!
Joey Lee

> 
> If anything, we should move to using the EFI RTC as a very last resort,
> i.e. 3 after 4.  Ideally we should match Win8 behavior, but that would
> require someone mocking up different ACPI and EFI functions in a
> simulator and see how Win8 prioritizes things.
> 
> 	-hpa
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[joeyli]

Hi hpa,  

於 五，2012-12-28 於 15:44 -0800，H. Peter Anvin 提到：
> On 12/28/2012 12:49 PM, Matthew Garrett wrote:
> > 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.
> > 
> 
> [Resending due to misconfigured tablet]
> 
> 3 before 2 is exactly what is known to break on existing hardware (ASUS).

I didn't find the EFI RTC problem on Asus from google. 
Could you please share what's the situation on ASUS hardware?


Thanks a lot!
Joey Lee

> 
> If anything, we should move to using the EFI RTC as a very last resort,
> i.e. 3 after 4.  Ideally we should match Win8 behavior, but that would
> require someone mocking up different ACPI and EFI functions in a
> simulator and see how Win8 prioritizes things.
> 
> 	-hpa
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[Matt Fleming]

On Wed, 2013-01-02 at 10:45 +0800, joeyli wrote:
> I didn't find the EFI RTC problem on Asus from google. 
> Could you please share what's the situation on ASUS hardware?

It's mentioned in the following commit (which has since been reverted in
Linus' tree),

commit 185034e72d591f9465e5e18f937ed642e7ea0070
Author: Matt Fleming <matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date:   Fri Sep 7 18:28:04 2012 +0100

    x86, efi: 1:1 pagetable mapping for virtual EFI calls
    
    Some firmware still needs a 1:1 (virt->phys) mapping even after we've
    called SetVirtualAddressMap(). So install the mapping alongside our
    existing kernel mapping whenever we make EFI calls in virtual mode.
    
    This bug was discovered on ASUS machines where the firmware
    implementation of GetTime() accesses the RTC device via physical
    addresses, even though that's bogus per the UEFI spec since we've
    informed the firmware via SetVirtualAddressMap() that the boottime
    memory map is no longer valid.
    
    This bug seems to be present in a lot of consumer devices, so there's
    not a lot we can do about this spec violation apart from workaround
    it.
    

The bug was originally mentioned here,

	https://lkml.org/lkml/2012/3/12/214

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[Matt Fleming]

On Wed, 2013-01-02 at 10:45 +0800, joeyli wrote:
> I didn't find the EFI RTC problem on Asus from google. 
> Could you please share what's the situation on ASUS hardware?

It's mentioned in the following commit (which has since been reverted in
Linus' tree),

commit 185034e72d591f9465e5e18f937ed642e7ea0070
Author: Matt Fleming <matt.fleming@intel.com>
Date:   Fri Sep 7 18:28:04 2012 +0100

    x86, efi: 1:1 pagetable mapping for virtual EFI calls
    
    Some firmware still needs a 1:1 (virt->phys) mapping even after we've
    called SetVirtualAddressMap(). So install the mapping alongside our
    existing kernel mapping whenever we make EFI calls in virtual mode.
    
    This bug was discovered on ASUS machines where the firmware
    implementation of GetTime() accesses the RTC device via physical
    addresses, even though that's bogus per the UEFI spec since we've
    informed the firmware via SetVirtualAddressMap() that the boottime
    memory map is no longer valid.
    
    This bug seems to be present in a lot of consumer devices, so there's
    not a lot we can do about this spec violation apart from workaround
    it.
    

The bug was originally mentioned here,

	https://lkml.org/lkml/2012/3/12/214

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[joeyli]

於 五，2012-12-28 於 17:43 +0000，Matthew Garrett 提到：
> On Sat, 2012-12-29 at 00:26 +0800, Lee, Chun-Yi wrote:
> > UEFI time services, GetTime(), SetTime(), GetWakeupTime(), SetWakeupTime() are also
> > supported by other non-IA64 architecutre with UEFI BIOS, e.g. x86.
> > 
> > This patch changed RTC_DRV_EFI configuration to depend on EFI but not just IA64. It
> > checks efi_enabled flag and efi-rtc driver should enabled.
> 
> In theory, certainly - but do we still have machines that explode if the
> get_time call is made? We may also want to think about disabling the
> legacy access to the RTC if the EFI calls are present.

The legacy get_time access on my test machine is work fine, not thing
explode. :-)
Just we have a function want to expose the timezone information to
userspace and also store it.


Thanks a lot!
Joey Lee

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[H. Peter Anvin]

On 12/28/2012 05:00 PM, joeyli wrote:
> 於 五，2012-12-28 於 17:43 +0000，Matthew Garrett 提到：
>> On Sat, 2012-12-29 at 00:26 +0800, Lee, Chun-Yi wrote:
>>> UEFI time services, GetTime(), SetTime(), GetWakeupTime(), SetWakeupTime() are also
>>> supported by other non-IA64 architecutre with UEFI BIOS, e.g. x86.
>>>
>>> This patch changed RTC_DRV_EFI configuration to depend on EFI but not just IA64. It
>>> checks efi_enabled flag and efi-rtc driver should enabled.
>>
>> In theory, certainly - but do we still have machines that explode if the
>> get_time call is made? We may also want to think about disabling the
>> legacy access to the RTC if the EFI calls are present.
> 
> The legacy get_time access on my test machine is work fine, not thing
> explode. :-)
> Just we have a function want to expose the timezone information to
> userspace and also store it.
> 

We should indeed save the timezone information if it is available --
either from the ACPI TAD or from the EFI RTC, or even via some
platform-dependent mechanism.  It is important, though, that that is
separate from the order of priority.

	-hpa

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[H. Peter Anvin]

On 12/28/2012 05:00 PM, joeyli wrote:
> 於 五，2012-12-28 於 17:43 +0000，Matthew Garrett 提到：
>> On Sat, 2012-12-29 at 00:26 +0800, Lee, Chun-Yi wrote:
>>> UEFI time services, GetTime(), SetTime(), GetWakeupTime(), SetWakeupTime() are also
>>> supported by other non-IA64 architecutre with UEFI BIOS, e.g. x86.
>>>
>>> This patch changed RTC_DRV_EFI configuration to depend on EFI but not just IA64. It
>>> checks efi_enabled flag and efi-rtc driver should enabled.
>>
>> In theory, certainly - but do we still have machines that explode if the
>> get_time call is made? We may also want to think about disabling the
>> legacy access to the RTC if the EFI calls are present.
> 
> The legacy get_time access on my test machine is work fine, not thing
> explode. :-)
> Just we have a function want to expose the timezone information to
> userspace and also store it.
> 

We should indeed save the timezone information if it is available --
either from the ACPI TAD or from the EFI RTC, or even via some
platform-dependent mechanism.  It is important, though, that that is
separate from the order of priority.

	-hpa

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[joeyli]

於 五，2012-12-28 於 17:07 -0800，H. Peter Anvin 提到：
> On 12/28/2012 05:00 PM, joeyli wrote:
> > 於 五，2012-12-28 於 17:43 +0000，Matthew Garrett 提到：
> >> On Sat, 2012-12-29 at 00:26 +0800, Lee, Chun-Yi wrote:
> >>> UEFI time services, GetTime(), SetTime(), GetWakeupTime(), SetWakeupTime() are also
> >>> supported by other non-IA64 architecutre with UEFI BIOS, e.g. x86.
> >>>
> >>> This patch changed RTC_DRV_EFI configuration to depend on EFI but not just IA64. It
> >>> checks efi_enabled flag and efi-rtc driver should enabled.
> >>
> >> In theory, certainly - but do we still have machines that explode if the
> >> get_time call is made? We may also want to think about disabling the
> >> legacy access to the RTC if the EFI calls are present.
> > 
> > The legacy get_time access on my test machine is work fine, not thing
> > explode. :-)
> > Just we have a function want to expose the timezone information to
> > userspace and also store it.
> > 
> 
> We should indeed save the timezone information if it is available --
> either from the ACPI TAD or from the EFI RTC, or even via some
> platform-dependent mechanism.  It is important, though, that that is
> separate from the order of priority.
> 
> 	-hpa
> 

I found Windows 8 doesn't aware/maintain the Timezone and Daylight
fields in EFI_TIME struct.

I got a Acer UEFI notebook and I keep the Windows 8 hard drive
(/dev/sda) but install Linux to another hard drive (/dev/sdb). 

On Linux, I applied my rtc-efi patches for allow user space feed
Timezone and store it to BIOS through SetTime(). I wrote a simple user
space program to set Timezone and Daylight fields, after set those
fields I reboot to Windows 8 and use DateTime setting GUI to look at the
change. Looks Windows doesn't aware the change, it just assume the time
in DateTime filed is local time, but didn't show the Timezone that was
set by me on Linux to GUI.

Then, I select another Timezone(country) through Windows 8 GUI, and
reboot to Linux. I read the Timezone and Daylight by program but didn't
see the Timezone and Daylight changed by Windows 8, the value is still
the same with my latest time setting by Linux program. Windows 8 changed
DayTime fields but didn't maintain Timezone and Daylight.

I only have this machine with preloaded Windows 8 for verify the
behavior, not sure it's normally or not. If Windows 8 ignores Timezone
and Daylight fields in UEFI BIOS, then I think it's lower down the
necessary for we maintain Timezone and Daylight in UEFI BIOS. 

We still can store Timezone and Daylight value to UEFI, but will have no
any interactive with Windows 8.

Appreciate for any suggestions.


Thanks a lot!
Joey Lee

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[joeyli]

於 五，2012-12-28 於 17:07 -0800，H. Peter Anvin 提到：
> On 12/28/2012 05:00 PM, joeyli wrote:
> > 於 五，2012-12-28 於 17:43 +0000，Matthew Garrett 提到：
> >> On Sat, 2012-12-29 at 00:26 +0800, Lee, Chun-Yi wrote:
> >>> UEFI time services, GetTime(), SetTime(), GetWakeupTime(), SetWakeupTime() are also
> >>> supported by other non-IA64 architecutre with UEFI BIOS, e.g. x86.
> >>>
> >>> This patch changed RTC_DRV_EFI configuration to depend on EFI but not just IA64. It
> >>> checks efi_enabled flag and efi-rtc driver should enabled.
> >>
> >> In theory, certainly - but do we still have machines that explode if the
> >> get_time call is made? We may also want to think about disabling the
> >> legacy access to the RTC if the EFI calls are present.
> > 
> > The legacy get_time access on my test machine is work fine, not thing
> > explode. :-)
> > Just we have a function want to expose the timezone information to
> > userspace and also store it.
> > 
> 
> We should indeed save the timezone information if it is available --
> either from the ACPI TAD or from the EFI RTC, or even via some
> platform-dependent mechanism.  It is important, though, that that is
> separate from the order of priority.
> 
> 	-hpa
> 

I found Windows 8 doesn't aware/maintain the Timezone and Daylight
fields in EFI_TIME struct.

I got a Acer UEFI notebook and I keep the Windows 8 hard drive
(/dev/sda) but install Linux to another hard drive (/dev/sdb). 

On Linux, I applied my rtc-efi patches for allow user space feed
Timezone and store it to BIOS through SetTime(). I wrote a simple user
space program to set Timezone and Daylight fields, after set those
fields I reboot to Windows 8 and use DateTime setting GUI to look at the
change. Looks Windows doesn't aware the change, it just assume the time
in DateTime filed is local time, but didn't show the Timezone that was
set by me on Linux to GUI.

Then, I select another Timezone(country) through Windows 8 GUI, and
reboot to Linux. I read the Timezone and Daylight by program but didn't
see the Timezone and Daylight changed by Windows 8, the value is still
the same with my latest time setting by Linux program. Windows 8 changed
DayTime fields but didn't maintain Timezone and Daylight.

I only have this machine with preloaded Windows 8 for verify the
behavior, not sure it's normally or not. If Windows 8 ignores Timezone
and Daylight fields in UEFI BIOS, then I think it's lower down the
necessary for we maintain Timezone and Daylight in UEFI BIOS. 

We still can store Timezone and Daylight value to UEFI, but will have no
any interactive with Windows 8.

Appreciate for any suggestions.


Thanks a lot!
Joey Lee

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[H. Peter Anvin]

That makes it even less compelling...

joeyli <jlee-IBi9RG/b67k@public.gmane.org> wrote:

>於 五，2012-12-28 於 17:07 -0800，H. Peter Anvin 提到：
>> On 12/28/2012 05:00 PM, joeyli wrote:
>> > 於 五，2012-12-28 於 17:43 +0000，Matthew Garrett 提到：
>> >> On Sat, 2012-12-29 at 00:26 +0800, Lee, Chun-Yi wrote:
>> >>> UEFI time services, GetTime(), SetTime(), GetWakeupTime(),
>SetWakeupTime() are also
>> >>> supported by other non-IA64 architecutre with UEFI BIOS, e.g.
>x86.
>> >>>
>> >>> This patch changed RTC_DRV_EFI configuration to depend on EFI but
>not just IA64. It
>> >>> checks efi_enabled flag and efi-rtc driver should enabled.
>> >>
>> >> In theory, certainly - but do we still have machines that explode
>if the
>> >> get_time call is made? We may also want to think about disabling
>the
>> >> legacy access to the RTC if the EFI calls are present.
>> > 
>> > The legacy get_time access on my test machine is work fine, not
>thing
>> > explode. :-)
>> > Just we have a function want to expose the timezone information to
>> > userspace and also store it.
>> > 
>> 
>> We should indeed save the timezone information if it is available --
>> either from the ACPI TAD or from the EFI RTC, or even via some
>> platform-dependent mechanism.  It is important, though, that that is
>> separate from the order of priority.
>> 
>> 	-hpa
>> 
>
>I found Windows 8 doesn't aware/maintain the Timezone and Daylight
>fields in EFI_TIME struct.
>
>I got a Acer UEFI notebook and I keep the Windows 8 hard drive
>(/dev/sda) but install Linux to another hard drive (/dev/sdb). 
>
>On Linux, I applied my rtc-efi patches for allow user space feed
>Timezone and store it to BIOS through SetTime(). I wrote a simple user
>space program to set Timezone and Daylight fields, after set those
>fields I reboot to Windows 8 and use DateTime setting GUI to look at
>the
>change. Looks Windows doesn't aware the change, it just assume the time
>in DateTime filed is local time, but didn't show the Timezone that was
>set by me on Linux to GUI.
>
>Then, I select another Timezone(country) through Windows 8 GUI, and
>reboot to Linux. I read the Timezone and Daylight by program but didn't
>see the Timezone and Daylight changed by Windows 8, the value is still
>the same with my latest time setting by Linux program. Windows 8
>changed
>DayTime fields but didn't maintain Timezone and Daylight.
>
>I only have this machine with preloaded Windows 8 for verify the
>behavior, not sure it's normally or not. If Windows 8 ignores Timezone
>and Daylight fields in UEFI BIOS, then I think it's lower down the
>necessary for we maintain Timezone and Daylight in UEFI BIOS. 
>
>We still can store Timezone and Daylight value to UEFI, but will have
>no
>any interactive with Windows 8.
>
>Appreciate for any suggestions.
>
>
>Thanks a lot!
>Joey Lee

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

Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

[H. Peter Anvin]

That makes it even less compelling...

joeyli <jlee@suse.com> wrote:

>於 五，2012-12-28 於 17:07 -0800，H. Peter Anvin 提到：
>> On 12/28/2012 05:00 PM, joeyli wrote:
>> > 於 五，2012-12-28 於 17:43 +0000，Matthew Garrett 提到：
>> >> On Sat, 2012-12-29 at 00:26 +0800, Lee, Chun-Yi wrote:
>> >>> UEFI time services, GetTime(), SetTime(), GetWakeupTime(),
>SetWakeupTime() are also
>> >>> supported by other non-IA64 architecutre with UEFI BIOS, e.g.
>x86.
>> >>>
>> >>> This patch changed RTC_DRV_EFI configuration to depend on EFI but
>not just IA64. It
>> >>> checks efi_enabled flag and efi-rtc driver should enabled.
>> >>
>> >> In theory, certainly - but do we still have machines that explode
>if the
>> >> get_time call is made? We may also want to think about disabling
>the
>> >> legacy access to the RTC if the EFI calls are present.
>> > 
>> > The legacy get_time access on my test machine is work fine, not
>thing
>> > explode. :-)
>> > Just we have a function want to expose the timezone information to
>> > userspace and also store it.
>> > 
>> 
>> We should indeed save the timezone information if it is available --
>> either from the ACPI TAD or from the EFI RTC, or even via some
>> platform-dependent mechanism.  It is important, though, that that is
>> separate from the order of priority.
>> 
>> 	-hpa
>> 
>
>I found Windows 8 doesn't aware/maintain the Timezone and Daylight
>fields in EFI_TIME struct.
>
>I got a Acer UEFI notebook and I keep the Windows 8 hard drive
>(/dev/sda) but install Linux to another hard drive (/dev/sdb). 
>
>On Linux, I applied my rtc-efi patches for allow user space feed
>Timezone and store it to BIOS through SetTime(). I wrote a simple user
>space program to set Timezone and Daylight fields, after set those
>fields I reboot to Windows 8 and use DateTime setting GUI to look at
>the
>change. Looks Windows doesn't aware the change, it just assume the time
>in DateTime filed is local time, but didn't show the Timezone that was
>set by me on Linux to GUI.
>
>Then, I select another Timezone(country) through Windows 8 GUI, and
>reboot to Linux. I read the Timezone and Daylight by program but didn't
>see the Timezone and Daylight changed by Windows 8, the value is still
>the same with my latest time setting by Linux program. Windows 8
>changed
>DayTime fields but didn't maintain Timezone and Daylight.
>
>I only have this machine with preloaded Windows 8 for verify the
>behavior, not sure it's normally or not. If Windows 8 ignores Timezone
>and Daylight fields in UEFI BIOS, then I think it's lower down the
>necessary for we maintain Timezone and Daylight in UEFI BIOS. 
>
>We still can store Timezone and Daylight value to UEFI, but will have
>no
>any interactive with Windows 8.
>
>Appreciate for any suggestions.
>
>
>Thanks a lot!
>Joey Lee

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