Re: rtc-cmos not supporting RTC_AIE?

David Brownell
2007-07-08T05:26:49Z

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