The use of tm_wday when setting an alarm time seems somewhat unclear.
The PCF506xx hardware supports a day-of-week match, but hardly anybody
provides a correct value for tm_wday. In its RTC_ALM_SET branch,
drivers/rtc/rtc-dev.c (rtc_dev_ioctl) sets it to -1 to indicate that
it's unused.
The most prudent approach seems to follow the example of mktime(3) and
just ignore all the non-essential fields. The other RTC drivers seem
to handle tm_mday in the same way.
We already ignore tm_yday and tm_isdst. This patch also makes us ignore
tm_wday. Tested on PCF50633, untested for PCF50606.
Signed-off-by: Werner Almesberger <[EMAIL PROTECTED]>
---
Index: ktrack/drivers/rtc/rtc-pcf50633.c
===================================================================
--- ktrack.orig/drivers/rtc/rtc-pcf50633.c 2008-12-04 01:15:12.000000000
-0200
+++ ktrack/drivers/rtc/rtc-pcf50633.c 2008-12-04 01:17:49.000000000 -0200
@@ -207,6 +207,9 @@
rtc2pcf_time(&pcf_tm, &alrm->time);
+ /* do like mktime does and ignore tm_wday */
+ pcf_tm.time[PCF50633_TI_WKDAY] = 7;
+
alarm_masked = pcf50633_irq_mask_get(pcf, PCF50633_IRQ_ALARM);
/* disable alarm interrupt */
Index: ktrack/drivers/rtc/rtc-pcf50606.c
===================================================================
--- ktrack.orig/drivers/rtc/rtc-pcf50606.c 2008-12-04 01:26:20.000000000
-0200
+++ ktrack/drivers/rtc/rtc-pcf50606.c 2008-12-04 01:28:32.000000000 -0200
@@ -207,6 +207,9 @@
rtc2pcf_time(&pcf_tm, &alrm->time);
+ /* do like mktime does and ignore tm_wday */
+ pcf_tm.time[PCF50606_TI_WKDAY] = 7;
+
alarm_masked = pcf50606_irq_mask_get(pcf, PCF50606_IRQ_ALARM);
/* disable alarm interrupt */
