From patchwork Mon Dec 1 22:13:46 2008 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Lord X-Patchwork-Id: 11660 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from yx-out-2122.google.com (yx-out-2122.google.com [74.125.44.26]) by ozlabs.org (Postfix) with ESMTP id 5DDE9DDD01 for ; Tue, 2 Dec 2008 09:12:46 +1100 (EST) Received: by yx-out-2122.google.com with SMTP id 35so769659yxh.11 for ; Mon, 01 Dec 2008 14:12:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:received:received:x-sender:x-apparently-to :received:received:received-spf:authentication-results:received :received:message-id:date:from:organization:user-agent:mime-version :content-type:to:cc:subject:references:in-reply-to:reply-to:sender :precedence:x-google-loop:mailing-list:list-id:list-post:list-help :list-unsubscribe:x-beenthere-env:x-beenthere; bh=qa3CVEPhUGJV4U0pijjaVxrZ4V7Ife4V9eDZ8KT/4xg=; b=Q/ufXIU261qCcLJ7Mz/LsEkbBzPBA0fhcbgjLdvXgPQzkrocpcwWl2AYCgvvlF6Rb5 WtK15Xk2G3JS5sfE5jf/2HbmDq1FOpfbAuhI6Rq0QnD5tswcahUYtEb0FFHPtW/giCwm 54VrWAG/pQibo28Afi2Rf7+0b7PFuXspkrMro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-sender:x-apparently-to:received-spf:authentication-results :message-id:date:from:organization:user-agent:mime-version :content-type:to:cc:subject:references:in-reply-to:reply-to:sender :precedence:x-google-loop:mailing-list:list-id:list-post:list-help :list-unsubscribe:x-beenthere-env:x-beenthere; b=VrSgPev8E8NaKvWYo6T/tCm/OdHkmaR1rqhVEHKtiPdvv2fGXlKI61hUAbCTzmUoPh ukjgeXV0ikhaON5ytXFA2tFOaW30opBeEWi3nhEZhIsk20Tt74+RQq66nS/QtJgxuTok cyJB74l4eql5A+P2yAyTj0PsEQn7DxFSX+rgY= Received: by 10.151.109.11 with SMTP id l11mr724934ybm.20.1228169561567; Mon, 01 Dec 2008 14:12:41 -0800 (PST) Received: by 10.176.251.38 with SMTP id y38gr1699yqh.0; Mon, 01 Dec 2008 14:12:41 -0800 (PST) X-Sender: lkml@rtr.ca X-Apparently-To: rtc-linux@googlegroups.com Received: by 10.90.93.17 with SMTP id q17mr3185361agb.6.1228169560593; Mon, 01 Dec 2008 14:12:40 -0800 (PST) Received: from mail.rtr.ca (rtr.ca [76.10.145.34]) by mx.google.com with ESMTP id 7si6387963yxg.0.2008.12.01.14.12.39; Mon, 01 Dec 2008 14:12:40 -0800 (PST) Received-SPF: pass (google.com: domain of lkml@rtr.ca designates 76.10.145.34 as permitted sender) client-ip=76.10.145.34; Authentication-Results: mx.google.com; spf=pass (google.com: domain of lkml@rtr.ca designates 76.10.145.34 as permitted sender) smtp.mail=lkml@rtr.ca Received: by mail.rtr.ca (Postfix, from userid 1002) id 4CC08E3E05B; Mon, 1 Dec 2008 17:13:47 -0500 (EST) Received: from [10.0.0.6] (corey.localnet [10.0.0.6]) by mail.rtr.ca (Postfix) with ESMTP id 1ABD7E3E05A; Mon, 1 Dec 2008 17:13:47 -0500 (EST) Message-ID: <4934619A.10809@rtr.ca> Date: Mon, 01 Dec 2008 17:13:46 -0500 From: Mark Lord Organization: Real-Time Remedies Inc. User-Agent: Thunderbird 2.0.0.18 (X11/20081125) Mime-Version: 1.0 To: Len Brown Cc: Alessandro Zummo , David Brownell , lkml , rtc-linux@googlegroups.com, linux-acpi@vger.kernel.org Subject: [rtc-linux] Re: PATCH: /proc/acpi/alarm: handle day-of-month wraparound on readback References: <200806222042.13929.david-b@pacbell.net> <4934176F.6080900@rtr.ca> In-Reply-To: Reply-To: rtc-linux@googlegroups.com Sender: rtc-linux@googlegroups.com Precedence: bulk X-Google-Loop: groups Mailing-List: list rtc-linux@googlegroups.com; contact rtc-linux+owner@googlegroups.com List-Id: List-Post: List-Help: List-Unsubscribe: , X-BeenThere-Env: rtc-linux@googlegroups.com X-BeenThere: rtc-linux@googlegroups.com Len Brown wrote: .. > We've had some BCD_TO_BIN() changes here in 2.6.28 already, > does 2.6.28-rc still have this bug? .. Yes, bug still there. Here is a version of the patch for 2.6.28-rc6 ---snip--- Fix month wrap issue with readback from /proc/acpi/alarm This bug has been around *forever*. $ echo '2008-12-01 10:36:20' > /proc/acpi/alarm $ cat /proc/acpi/alarm 2008-11-01 10:36:20 Note how the readback above shows the month incorrectly. But with this patch applied, it shows the correct month (12). This patch applies/works on 2.6.28-rc6. Probably best to queue it up for the next major cycle. Signed-off-by: Mark Lord --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. -~----------~----~----~----~------~----~------~--~--- --- linux/drivers/acpi/sleep/proc.c 2008-11-20 18:19:22.000000000 -0500 +++ linux-2.6.28-rc6/drivers/acpi/sleep/proc.c 2008-12-01 17:07:51.000000000 -0500 @@ -84,12 +84,15 @@ #define HAVE_ACPI_LEGACY_ALARM #endif +static u32 cmos_bcd_read(int offset, int rtc_control); + #ifdef HAVE_ACPI_LEGACY_ALARM static int acpi_system_alarm_seq_show(struct seq_file *seq, void *offset) { u32 sec, min, hr; u32 day, mo, yr, cent = 0; + u32 today = 0; unsigned char rtc_control = 0; unsigned long flags; @@ -97,38 +100,32 @@ spin_lock_irqsave(&rtc_lock, flags); - sec = CMOS_READ(RTC_SECONDS_ALARM); - min = CMOS_READ(RTC_MINUTES_ALARM); - hr = CMOS_READ(RTC_HOURS_ALARM); rtc_control = CMOS_READ(RTC_CONTROL); + sec = cmos_bcd_read(RTC_SECONDS_ALARM, rtc_control); + min = cmos_bcd_read(RTC_MINUTES_ALARM, rtc_control); + hr = cmos_bcd_read(RTC_HOURS_ALARM, rtc_control); /* If we ever get an FACP with proper values... */ - if (acpi_gbl_FADT.day_alarm) + if (acpi_gbl_FADT.day_alarm) { /* ACPI spec: only low 6 its should be cared */ day = CMOS_READ(acpi_gbl_FADT.day_alarm) & 0x3F; - else - day = CMOS_READ(RTC_DAY_OF_MONTH); + if (!(rtc_control & RTC_DM_BINARY) || RTC_ALWAYS_BCD) + day = bcd2bin(day); + } else + day = cmos_bcd_read(RTC_DAY_OF_MONTH, rtc_control); if (acpi_gbl_FADT.month_alarm) - mo = CMOS_READ(acpi_gbl_FADT.month_alarm); - else - mo = CMOS_READ(RTC_MONTH); + mo = cmos_bcd_read(acpi_gbl_FADT.month_alarm, rtc_control); + else { + mo = cmos_bcd_read(RTC_MONTH, rtc_control); + today = cmos_bcd_read(RTC_DAY_OF_MONTH, rtc_control); + } if (acpi_gbl_FADT.century) - cent = CMOS_READ(acpi_gbl_FADT.century); + cent = cmos_bcd_read(acpi_gbl_FADT.century, rtc_control); - yr = CMOS_READ(RTC_YEAR); + yr = cmos_bcd_read(RTC_YEAR, rtc_control); spin_unlock_irqrestore(&rtc_lock, flags); - if (!(rtc_control & RTC_DM_BINARY) || RTC_ALWAYS_BCD) { - sec = bcd2bin(sec); - min = bcd2bin(min); - hr = bcd2bin(hr); - day = bcd2bin(day); - mo = bcd2bin(mo); - yr = bcd2bin(yr); - cent = bcd2bin(cent); - } - /* we're trusting the FADT (see above) */ if (!acpi_gbl_FADT.century) /* If we're not trusting the FADT, we should at least make it @@ -153,6 +150,20 @@ else yr += cent * 100; + /* + * Show correct dates for alarms up to a month into the future. + * This solves issues for nearly all situations with the common + * 30-day alarm clocks in PC hardware. + */ + if (day < today) { + if (mo < 12) { + mo += 1; + } else { + mo = 1; + yr += 1; + } + } + seq_printf(seq, "%4.4u-", yr); (mo > 12) ? seq_puts(seq, "**-") : seq_printf(seq, "%2.2u-", mo); (day > 31) ? seq_puts(seq, "** ") : seq_printf(seq, "%2.2u ", day);