On Saturday 07 July 2007, Marcelo Tosatti wrote: > > David, > > Is there any reason why programs using RTC_AIE/RTC_ALM_SET ioctls are > unable to arm alarm irq's? The ALM_SET request never did! And I'm pretty sure AIE_ON does indeed set it ... the test cases use ALM_SET then AIE_ON, which is the "traditional" idiom (i.e. legacy drivers/char/rtc.c idiom). > I'm aware of the new RTC_WKALM_SET... but shouldnt backward > compatibility be kept? According to <linux/rtc.h> the ALM_SET ioctl takes an rtc_time, while WKALM_SET takes an rtc_wkalm ... which differs from the former by including the flag controlling wheter the alarm will be enabled (or not) when setting the alarm. (Model inherited from EFI.) > The code seems to imply that its not supported anymore, however ioctl > returns success but no alarm is fired (for instance alarm.enabled is set > to 0): > > case RTC_ALM_SET: > if (copy_from_user(&alarm.time, uarg, sizeof(tm))) > return -EFAULT; > > alarm.enabled = 0; > alarm.pending = 0; > alarm.time.tm_wday = -1; > alarm.time.tm_yday = -1; > alarm.time.tm_isdst = -1; That code is generic RTC framework code (rtc-dev.c), and not code specific to rtc-cmos ... the comment immediately following that (2.6.22-rc7 and previous) should clarify many of the issues. I think the current manpage does the same. (If it mentions the /dev/rtc0, /dev/rtc1, etc files, it should be current enough.) What it does is just stuff the rtc_time into the expanded rtc_wkalm. The idea is that the RTC drivers only support one alarm-setting method, but the /dev/rtcN ioctl interface uses it in two modes: - "legacy", up to 24 hours in the future, and requiring the alarm to be enabled later with AIE_ON; - "EFI-style", into the arbitrary future, and bundling the flag saying whether to enable the alarm. Since ALM_SET is the legacy mode, it requires separate AIE_ON (from the RTC driver directly). But RTC_WKALM_SET doesn't. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html