Minor logic fix. The century change was previously always BCD,
even when the CMOS data would report itself not being BCD.
Signed-off-by: Andi Kleen <[email protected]>
---
arch/x86/kernel/rtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/arch/x86/kernel/rtc.c
===================================================================
--- linux.orig/arch/x86/kernel/rtc.c
+++ linux/arch/x86/kernel/rtc.c
@@ -130,10 +130,10 @@ unsigned long mach_get_cmos_time(void)
BCD_TO_BIN(day);
BCD_TO_BIN(mon);
BCD_TO_BIN(year);
+ BCD_TO_BIN(century);
}
if (century) {
- BCD_TO_BIN(century);
year += century * 100;
printk(KERN_INFO "Extended CMOS year: %d\n", century * 100);
} else {
We know it is already after 2000.
This extends the effective lifetime of 32bit systems by 8 years:
from 2030 to 2038.
The only drawback is that users cannot set the cmos date to before 2000
now on 32bit with systems that don't support extended century in
the RTC clock. 64bit systems had this limitation for some time
and nobody complained.
And they can always set it to such a date in Linux only using date -s
if they really want.
Signed-off-by: Andi Kleen <[email protected]>
---
arch/x86/kernel/rtc.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
Index: linux/arch/x86/kernel/rtc.c
===================================================================
--- linux.orig/arch/x86/kernel/rtc.c
+++ linux/arch/x86/kernel/rtc.c
@@ -9,7 +9,6 @@
#include <asm/vsyscall.h>
#ifdef CONFIG_X86_32
-# define CMOS_YEARS_OFFS 1900
/*
* This is a special lock that is owned by the CPU and holds the index
* register we are working with. It is required for NMI access to the
@@ -17,14 +16,11 @@
*/
volatile unsigned long cmos_lock = 0;
EXPORT_SYMBOL(cmos_lock);
-#else
-/*
- * x86-64 systems only exists since 2002.
- * This will work up to Dec 31, 2100
- */
-# define CMOS_YEARS_OFFS 2000
#endif
+/* For two digit years assume time is always after that */
+#define CMOS_YEARS_OFFS 2000
+
DEFINE_SPINLOCK(rtc_lock);
EXPORT_SYMBOL(rtc_lock);
Not that it matters much, see comment in the code.
Signed-off-by: Andi Kleen <[email protected]>
---
arch/x86/kernel/rtc.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
Index: linux/arch/x86/kernel/rtc.c
===================================================================
--- linux.orig/arch/x86/kernel/rtc.c
+++ linux/arch/x86/kernel/rtc.c
@@ -112,12 +112,13 @@ unsigned long mach_get_cmos_time(void)
mon = CMOS_READ(RTC_MONTH);
year = CMOS_READ(RTC_YEAR);
-#if defined(CONFIG_ACPI) && defined(CONFIG_X86_64)
- /* CHECKME: Is this really 64bit only ??? */
+ /*
+ * On 32bit not strictly needed because the world ends in 2038
+ * and the code can handle that with the 2 digit heuristics.
+ */
if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
acpi_gbl_FADT.century)
century = CMOS_READ(acpi_gbl_FADT.century);
-#endif
if (RTC_ALWAYS_BCD || !(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY)) {
BCD_TO_BIN(sec);
On Fri, 8 Feb 2008, Andi Kleen wrote:
>
> Minor logic fix. The century change was previously always BCD,
> even when the CMOS data would report itself not being BCD.
Where was it previously always BCD ?
The code flow is taken 1:1 from the original x8664 code. Just the
BCD_TO_BIN code has been made conditional for i386, which is not
chanining the logic at all, because RTC_ALWAYS_BCD is always true on
x8664.
While your change does not do any harm due to BCD_TO_BIN(0) = 0, it
is just not fixing anything.
Thanks,
tglx
> Signed-off-by: Andi Kleen <[email protected]>
>
> ---
> arch/x86/kernel/rtc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux/arch/x86/kernel/rtc.c
> ===================================================================
> --- linux.orig/arch/x86/kernel/rtc.c
> +++ linux/arch/x86/kernel/rtc.c
> @@ -130,10 +130,10 @@ unsigned long mach_get_cmos_time(void)
> BCD_TO_BIN(day);
> BCD_TO_BIN(mon);
> BCD_TO_BIN(year);
> + BCD_TO_BIN(century);
> }
>
> if (century) {
> - BCD_TO_BIN(century);
> year += century * 100;
> printk(KERN_INFO "Extended CMOS year: %d\n", century * 100);
> } else {
>
On Fri, 8 Feb 2008, Andi Kleen wrote:
>
> Not that it matters much, see comment in the code.
>
> Signed-off-by: Andi Kleen <[email protected]>
>
> ---
> arch/x86/kernel/rtc.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> Index: linux/arch/x86/kernel/rtc.c
> ===================================================================
> --- linux.orig/arch/x86/kernel/rtc.c
> +++ linux/arch/x86/kernel/rtc.c
> @@ -112,12 +112,13 @@ unsigned long mach_get_cmos_time(void)
> mon = CMOS_READ(RTC_MONTH);
> year = CMOS_READ(RTC_YEAR);
>
> -#if defined(CONFIG_ACPI) && defined(CONFIG_X86_64)
> - /* CHECKME: Is this really 64bit only ??? */
> + /*
> + * On 32bit not strictly needed because the world ends in 2038
> + * and the code can handle that with the 2 digit heuristics.
> + */
> if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
> acpi_gbl_FADT.century)
> century = CMOS_READ(acpi_gbl_FADT.century);
How does this compile with CONFIG_ACPI=n ?
Thanks,
tglx
On Sat, Feb 09, 2008 at 11:28:01AM +0100, Thomas Gleixner wrote:
> On Fri, 8 Feb 2008, Andi Kleen wrote:
>
> >
> > Minor logic fix. The century change was previously always BCD,
> > even when the CMOS data would report itself not being BCD.
>
> Where was it previously always BCD ?
>
> The code flow is taken 1:1 from the original x8664 code. Just the
> BCD_TO_BIN code has been made conditional for i386, which is not
> chanining the logic at all, because RTC_ALWAYS_BCD is always true on
> x8664.
Ah that's true -- i missed that indeed. I don't actually
remember why it was hardcoded like this on x86-64. I don't think
there is a good reason for it and if there's a bit for this
in the CMOS it ought be better checked.
>
> While your change does not do any harm due to BCD_TO_BIN(0) = 0, it
> is just not fixing anything.
In theory it would make sense with the followup change to
do the extended century on 32bit too, but in practice all these
systems should be BCD anyways (I hope)
-Andi