summaryrefslogtreecommitdiffstats
path: root/drivers/rtc/rtc-dev.c
diff options
context:
space:
mode:
authorDavid Brownell <david-b@pacbell.net>2007-05-08 00:34:07 -0700
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-05-08 11:15:19 -0700
commitf8245c26886c912627ebc49f714e4491261224c4 (patch)
tree132a34d1e482f96a5d4bba5f744658aea9a5fcc9 /drivers/rtc/rtc-dev.c
parent416ce32e704d778c283f2f86cadd836cd5d3696c (diff)
downloadlinux-f8245c26886c912627ebc49f714e4491261224c4.tar.bz2
rtc: remove "RTC_ALM_SET mode" bugs
This fixes a common glitch in how RTC drivers handle two "set alarm" modes, by getting rid of the surprising/hidden one that was rarely implemented correctly (and which could expose nonportable hardware-specific behavior). The glitch comes from the /dev/rtcX logic implementing the legacy RTC_ALM_SET (limited to 24 hours, needing RTC_AIE_ON) ioctl on top of the RTC driver call providing access to the newer RTC_WKALM_SET (without those limitations) by initializing the day/month/year fields to be invalid ... that second mode. Now, since few RTC drivers check those fields, and most hardware misbehaves when faced with invalid date fields, many RTC drivers will set bogus alarm times on those RTC_ALM_SET code paths. (Several in-tree drivers have that issue, and I also noticed it with code reviews on several new RTC drivers.) This patch ensures that RTC drivers never see such invalid alarm fields, by moving some logic out of rtc-omap into the RTC_ALM_SET code and adding an explicit check (which will prevent the issue on other code paths). Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Scott Wood <scottwood@freescale.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/rtc/rtc-dev.c')
-rw-r--r--drivers/rtc/rtc-dev.c42
1 files changed, 39 insertions, 3 deletions
diff --git a/drivers/rtc/rtc-dev.c b/drivers/rtc/rtc-dev.c
index 671b14ec28bb..f4e5f0040ff7 100644
--- a/drivers/rtc/rtc-dev.c
+++ b/drivers/rtc/rtc-dev.c
@@ -277,12 +277,48 @@ static int rtc_dev_ioctl(struct inode *inode, struct file *file,
alarm.enabled = 0;
alarm.pending = 0;
- alarm.time.tm_mday = -1;
- alarm.time.tm_mon = -1;
- alarm.time.tm_year = -1;
alarm.time.tm_wday = -1;
alarm.time.tm_yday = -1;
alarm.time.tm_isdst = -1;
+
+ /* RTC_ALM_SET alarms may be up to 24 hours in the future.
+ * Rather than expecting every RTC to implement "don't care"
+ * for day/month/year fields, just force the alarm to have
+ * the right values for those fields.
+ *
+ * RTC_WKALM_SET should be used instead. Not only does it
+ * eliminate the need for a separate RTC_AIE_ON call, it
+ * doesn't have the "alarm 23:59:59 in the future" race.
+ *
+ * NOTE: some legacy code may have used invalid fields as
+ * wildcards, exposing hardware "periodic alarm" capabilities.
+ * Not supported here.
+ */
+ {
+ unsigned long now, then;
+
+ err = rtc_read_time(rtc, &tm);
+ if (err < 0)
+ return err;
+ rtc_tm_to_time(&tm, &now);
+
+ alarm.time.tm_mday = tm.tm_mday;
+ alarm.time.tm_mon = tm.tm_mon;
+ alarm.time.tm_year = tm.tm_year;
+ err = rtc_valid_tm(&alarm.time);
+ if (err < 0)
+ return err;
+ rtc_tm_to_time(&alarm.time, &then);
+
+ /* alarm may need to wrap into tomorrow */
+ if (then < now) {
+ rtc_time_to_tm(now + 24 * 60 * 60, &tm);
+ alarm.time.tm_mday = tm.tm_mday;
+ alarm.time.tm_mon = tm.tm_mon;
+ alarm.time.tm_year = tm.tm_year;
+ }
+ }
+
err = rtc_set_alarm(rtc, &alarm);
break;