linux-stable.git/drivers/rtc/interface.c, branch linux-5.10.y

rtc: interface: Alarm race handling should not discard preceding error

2026-03-04T12:19:50+00:00

[ Upstream commit 81be22cd4ace020045cc6d31255c6f7c071eb7c0 ]

Commit 795cda8338ea ("rtc: interface: Fix long-standing race when setting
alarm") should not discard any errors from the preceding validations.

Prior to that commit, if the alarm feature was disabled, or the
set_alarm failed, a meaningful error code would be returned to the
caller for further action.

After, more often than not, the __rtc_read_time will cause a success
return code instead, misleading the caller.

An example of this is when timer_enqueue is called for a rtc-abx080x
device. Since that driver does not clear the alarm feature bit, but
instead relies on the set_alarm operation to return invalid, the discard
of the return code causes very different behaviour; i.e.
    hwclock: select() to /dev/rtc0 to wait for clock tick timed out

Fixes: 795cda8338ea ("rtc: interface: Fix long-standing race when setting alarm")
Signed-off-by: Anthony Pighin (Nokia) 
Reviewed-by: Esben Haabendal 
Tested-by: Nick Bowler 
Link: https://patch.msgid.link/BN0PR08MB6951415A751F236375A2945683D1A@BN0PR08MB6951.namprd08.prod.outlook.com
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin

rtc: interface: Fix long-standing race when setting alarm

2025-10-29T13:01:12+00:00

commit 795cda8338eab036013314dbc0b04aae728880ab upstream.

As described in the old comment dating back to
commit 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events")
from 2010, we have been living with a race window when setting alarm
with an expiry in the near future (i.e. next second).
With 1 second resolution, it can happen that the second ticks after the
check for the timer having expired, but before the alarm is actually set.
When this happen, no alarm IRQ is generated, at least not with some RTC
chips (isl12022 is an example of this).

With UIE RTC timer being implemented on top of alarm irq, being re-armed
every second, UIE will occasionally fail to work, as an alarm irq lost
due to this race will stop the re-arming loop.

For now, I have limited the additional expiry check to only be done for
alarms set to next seconds. I expect it should be good enough, although I
don't know if we can now for sure that systems with loads could end up
causing the same problems for alarms set 2 seconds or even longer in the
future.

I haven't been able to reproduce the problem with this check in place.

Cc: stable@vger.kernel.org
Signed-off-by: Esben Haabendal 
Link: https://lore.kernel.org/r/20250516-rtc-uie-irq-fixes-v2-1-3de8e530a39e@geanix.com
Signed-off-by: Alexandre Belloni 
Signed-off-by: Greg Kroah-Hartman

rtc: interface: Ensure alarm irq is enabled when UIE is enabled

2025-10-29T13:01:12+00:00

commit 9db26d5855d0374d4652487bfb5aacf40821c469 upstream.

When setting a normal alarm, user-space is responsible for using
RTC_AIE_ON/RTC_AIE_OFF to control if alarm irq should be enabled.

But when RTC_UIE_ON is used, interrupts must be enabled so that the
requested irq events are generated.
When RTC_UIE_OFF is used, alarm irq is disabled if there are no other
alarms queued, so this commit brings symmetry to that.

Signed-off-by: Esben Haabendal 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20250516-rtc-uie-irq-fixes-v2-5-3de8e530a39e@geanix.com
Signed-off-by: Alexandre Belloni 
Signed-off-by: Greg Kroah-Hartman

rtc: check if __rtc_read_time was successful in rtc_timer_do_work()

2024-12-14T18:48:14+00:00

[ Upstream commit e8ba8a2bc4f60a1065f23d6a0e7cbea945a0f40d ]

If the __rtc_read_time call fails,, the struct rtc_time tm; may contain
uninitialized data, or an illegal date/time read from the RTC hardware.

When calling rtc_tm_to_ktime later, the result may be a very large value
(possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue,
they will continually expire, may causing kernel softlockup.

Fixes: 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events")
Signed-off-by: Yongliang Gao 
Acked-by: Jingqun Li 
Link: https://lore.kernel.org/r/20241011043153.3788112-1-leonylgao@gmail.com
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin

rtc: interface: Add RTC offset to alarm after fix-up

2024-08-19T03:40:54+00:00

[ Upstream commit 463927a8902a9f22c3633960119410f57d4c8920 ]

`rtc_add_offset()` is called by `__rtc_read_time()`
and `__rtc_read_alarm()` to add the RTC's offset to
the raw read-outs from the device drivers. However,
in the latter case, a fix-up algorithm is run if
the RTC device does not report a full `struct rtc_time`
alarm value. In that case, the offset was forgot to be
added.

Fixes: fd6792bb022e ("rtc: fix alarm read and set offset")

Signed-off-by: Csókás, Bence 
Link: https://lore.kernel.org/r/20240619140451.2800578-1-csokas.bence@prolan.hu
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin

rtc: check if __rtc_read_time was successful

2022-04-08T12:40:40+00:00

commit 915593a7a663b2ad08b895a5f3ba8b19d89d4ebf upstream.

Clang static analysis reports this issue
interface.c:810:8: warning: Passed-by-value struct
  argument contains uninitialized data
  now = rtc_tm_to_ktime(tm);
      ^~~~~~~~~~~~~~~~~~~

tm is set by a successful call to __rtc_read_time()
but its return status is not checked.  Check if
it was successful before setting the enabled flag.
Move the decl of err to function scope.

Fixes: 2b2f5ff00f63 ("rtc: interface: ignore expired timers when enqueuing new timers")
Signed-off-by: Tom Rix 
Signed-off-by: Alexandre Belloni 
Link: https://lore.kernel.org/r/20220326194236.2916310-1-trix@redhat.com
Signed-off-by: Greg Kroah-Hartman

rtc: interface: fix kerneldoc comments

2019-11-27T08:31:08+00:00

Fix kerneldoc warnings:

drivers/rtc/interface.c:619: warning: Function parameter or member 'num' not described in 'rtc_handle_legacy_irq'
drivers/rtc/interface.c:619: warning: Function parameter or member 'mode' not described in 'rtc_handle_legacy_irq'
drivers/rtc/interface.c:804: warning: Function parameter or member 'rtc' not described in 'rtc_timer_enqueue'
drivers/rtc/interface.c:804: warning: Function parameter or member 'timer' not described in 'rtc_timer_enqueue'
drivers/rtc/interface.c:864: warning: Function parameter or member 'rtc' not described in 'rtc_timer_remove'
drivers/rtc/interface.c:864: warning: Function parameter or member 'timer' not described in 'rtc_timer_remove'
drivers/rtc/interface.c:900: warning: Function parameter or member 'work' not described in 'rtc_timer_do_work'
drivers/rtc/interface.c:1035: warning: Function parameter or member 'rtc' not described in 'rtc_read_offset'
drivers/rtc/interface.c:1035: warning: Function parameter or member 'offset' not described in 'rtc_read_offset'
drivers/rtc/interface.c:1070: warning: Function parameter or member 'rtc' not described in 'rtc_set_offset'
drivers/rtc/interface.c:1070: warning: Function parameter or member 'offset' not described in 'rtc_set_offset'

Link: https://lore.kernel.org/r/20191127082932.666869-1-alexandre.belloni@bootlin.com
Signed-off-by: Alexandre Belloni

rtc: disallow update interrupts when time is invalid

2019-11-08T15:14:09+00:00

Never enable update interrupts when the time set on the rtc is invalid.
In that case, also avoid enabling the emulation because it will fail for
the same reason.

Link: https://lore.kernel.org/r/20191021155631.3342-2-alexandre.belloni@bootlin.com
Link: https://lore.kernel.org/r/CA+ASDXMarBG5C1Kz42B9i_iVZ1=i6GgH9Yja2cdmSueKD_As_g@mail.gmail.com
Reported-by: Jeffy Chen 
Reported-by: Brian Norris 
Signed-off-by: Alexandre Belloni

rtc: disable uie before setting time and enable after

2019-11-08T15:14:09+00:00

When setting the time in the future with the uie timer enabled,
rtc_timer_do_work will loop for a while because the expiration of the uie
timer was way before the current RTC time and a new timer will be enqueued
until the current rtc time is reached.

If the uie timer is enabled, disable it before setting the time and enable
it after expiring current timers (which may actually be an alarm).

This is the safest thing to do to ensure the uie timer is still
synchronized with the RTC, especially in the UIE emulation case.

Reported-by: syzbot+08116743f8ad6f9a6de7@syzkaller.appspotmail.com
Fixes: 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events")
Link: https://lore.kernel.org/r/20191020231320.8191-1-alexandre.belloni@bootlin.com
Signed-off-by: Alexandre Belloni

rtc: interface: use timeu64_t for range_max

2019-10-03T19:55:17+00:00

For rtc drivers where rtc->range_max is set U64_MAX, like the PS3 rtc,
rtc_valid_range() always returns -ERANGE. This is because the local
variable range_max has type time64_t, so the test
	if (time < range_min || time > range_max)
		return -ERANGE;
becomes (time < range_min || time > -1), which always evaluates to true.
timeu64_t should be used, since it's the type of rtc->range_max.

Signed-off-by: Emmanuel Nicolet 
Link: https://lore.kernel.org/r/20190927110446.GA6289@gmail.com
Signed-off-by: Alexandre Belloni