Re: [PATCH] rtc: Don't lose a minute-resolution alarm that rounds down into the past

[Arun Iyengar]

Hi Alexandre,

> This is the expected behaviour, userspace has to handle the error
> properly: the alarm can't be set, set it for a later time or stop there
> and don't suspend.

OK. One detail: userspace gets no error in this case.
rtc_timer_enqueue() turns the -ETIME from __rtc_set_alarm() into an
immediate expiry and returns 0, so RTC_WKALM_SET and the wakealarm
sysfs file succeed. What userspace gets is an RTC_AF event right away
and a disabled alarm from RTC_WKALM_RD.

I checked that on the HYM8563 without my patch: RTC_WKALM_SET for 15 s
ahead in the current minute returned 0 in 5 of 5 tries. rtcwake only
checks that return value, so "rtcwake -m freeze -s 15" suspended with
no alarm armed and did not wake up.

> Never round up, you are going to miss deadlines.

Understood, please drop the patch. I'll fix rtcwake instead: read the
alarm back after setting it and not suspend when it has already
expired.

Would you also want rtc_set_alarm() to return -ETIME when the rounding
moves an alarm that is still in the future into the past? If the
immediate RTC_AF is the intended signal, I'll leave the kernel as it
is.

Thanks,
Arun

On Mon, Nov 9, 2026 at 11:48 PM Alexandre Belloni
<alexandre.belloni@xxxxxxxxxxx> wrote:
>
> On 10/11/2026 07:13:47+0000, Arun Iyengar via B4 Relay wrote:
> > From: Arun Iyengar <aiyengar1990@xxxxxxxxx>
> >
> > For an RTC with RTC_FEATURE_ALARM_RES_MINUTE, rtc_set_alarm() rounds the
> > alarm down to the start of its minute, so that it never fires late. When
> > the alarm is less than a minute away and in the same minute as the
> > current time, the rounded time is already in the past.
> > rtc_timer_enqueue() then gets -ETIME from __rtc_set_alarm() and expires
> > the timer from the irq work right away, and the hardware alarm is never
> > armed.
>
> This is the expected behaviour, userspace has to handle the error
> properly: the alarm can't be set, set it for a later time or stop there
> and don't suspend.
>
> >
> > That loses every short wake alarm. With a HYM8563, which has minute
> > resolution, "rtcwake -m freeze -s 15" sets an alarm that expires in
> > software before the system suspends, so nothing wakes it: with the
> > alarm set at 17:55:00 for 17:55:17, /proc/driver/rtc reads back
> > "alrm_time: 17:55:00, alarm_IRQ: no", and the system stays in
> > suspend-to-idle until something else wakes it.
> >
> > Round the alarm up to the next minute when rounding down would put an
> > alarm that is still in the future into the past. It then fires at most
> > 59 seconds late instead of never. Alarms that are already in the past,
> > or that round down to a time still in the future, are handled as before.
>
> Never round up, you are going to miss deadlines.
>
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com