From 6954bee829a037e4a3e06f7ecd7fc0466fadde41 Mon Sep 17 00:00:00 2001 From: Andi Kleen Date: Sat, 25 Mar 2006 16:30:31 +0100 Subject: [PATCH] x86_64: Handle years beyond 2100 ACPIv2 has an official but optional way to get a date >2100. Use it. But all the platforms I tested didn't seem to support it. But anyways the x86-64 kernel should be ready for the 22nd century now. Actually i shouldn't care about this because I will be dead by then @) Signed-off-by: Andi Kleen Signed-off-by: Linus Torvalds --- arch/x86_64/kernel/time.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/arch/x86_64/kernel/time.c b/arch/x86_64/kernel/time.c index 86039baaaf1..2f7c2120657 100644 --- a/arch/x86_64/kernel/time.c +++ b/arch/x86_64/kernel/time.c @@ -517,6 +517,7 @@ static unsigned long get_cmos_time(void) unsigned int timeout = 1000000, year, mon, day, hour, min, sec; unsigned char uip = 0, this = 0; unsigned long flags; + unsigned extyear = 0; /* * The Linux interpretation of the CMOS clock register contents: When the @@ -545,6 +546,11 @@ static unsigned long get_cmos_time(void) mon = CMOS_READ(RTC_MONTH); year = CMOS_READ(RTC_YEAR); +#ifdef CONFIG_ACPI + if (acpi_fadt.revision >= FADT2_REVISION_ID && acpi_fadt.century) + extyear = CMOS_READ(acpi_fadt.century); +#endif + spin_unlock_irqrestore(&rtc_lock, flags); /* @@ -559,11 +565,17 @@ static unsigned long get_cmos_time(void) BCD_TO_BIN(mon); BCD_TO_BIN(year); - /* - * x86-64 systems only exists since 2002. - * This will work up to Dec 31, 2100 - */ - year += 2000; + if (extyear) { + BCD_TO_BIN(extyear); + year += extyear; + printk(KERN_INFO "Extended CMOS year: %d\n", extyear); + } else { + /* + * x86-64 systems only exists since 2002. + * This will work up to Dec 31, 2100 + */ + year += 2000; + } return mktime(year, mon, day, hour, min, sec); } -- cgit v1.2.3