Some alarm timers are based on time offsets, not on absolute times.
In some situations, the amount of time that can be scheduled in the
future is limited. This may result in a refusal to suspend the system,
causing substantial battery drain.
This problem was previously observed on a Chromebook using the cros_ec
rtc driver. EC variants on some older Chromebooks only support 24 hours
of alarm time in the future. To work around the problem on affected
Chromebooks, code to limit the maximum alarm time was added to the cros_ec
rtc driver with commit f27efee66370 ("rtc: cros-ec: Limit RTC alarm range
if needed"). The problem is now seen again on a system using the cmos
RTC driver on hardware limited to 24 hours of alarm time, so a more
generic solution is needed.
Some RTC drivers remedy the situation by setting the alarm time to the
maximum supported time if a request for an out-of-range timeout is made.
This is not really desirable since it may result in unexpected early
wakeups. It would be even more undesirable to change the behavior
of existing widely used drivers such as the cmos RTC driver.
The existing range_max variable in struct rtc_device can not be used
to determine the maximum time offset supported by an rtc chip since
it describes the maximum absolute time supported by the chip, not the
maximum time offset that can be set for alarms.
To reduce the impact of this problem, introduce a new variable
rtc_time_offset in struct rtc_device to let RTC drivers report the maximum
supported alarm time offset. The code setting alarm timers can then
decide if it wants to reject setting alarm timers to a larger value, if it
wants to implement recurring alarms until the actually requested alarm
time is met, or if it wants to accept the limited alarm time. Use the new
variable to limit the alarm timer range.
The series is intended to solve the problem with minimal changes in the
rtc core and in affected drivers.
An alternative I had considered was to have the alarmtimer code guess the
maximum timeout supported by the rtc hardware. I discarded it as less
desirable since it had to retry repeatedly depending on rtc limitations.
This often resulted in error messages by the rtc driver. On top of that,
it was all but impossible to support rtc chips such as tps6586x which
can only support wake alarms up to 16,383 seconds in the future.
The first patch of the series adds support for providing the maximum
supported time offset to the rtc core. The second patch uses that value
in the alarmtimer code to set the maximum wake-up time from system suspend.
Subsequent patches add support for reporting the maximum alarm timer offset
to a subset of affected drivers.
Previous discussion:
https://lore.kernel.org/lkml/Y19AdIntJZGnBh%2Fy@xxxxxxxxxx/T/#mc06d206d5bdb77c613712148818934b4f5640de5
----------------------------------------------------------------
Guenter Roeck (7):
rtc: Add support for limited alarm timer offsets
rtc: alarmtimer: Use maximum alarm time offset
rtc: cros-ec: Detect and report supported alarm window size
rtc: cmos: Report supported alarm limit to rtc infrastructure
rtc: tps6586x: Report maximum alarm limit to rtc core
rtc: ds1305: Report maximum alarm limit to rtc core
rtc: rzn1: Report maximum alarm limit to rtc core
drivers/rtc/rtc-cmos.c | 11 +++++++++++
drivers/rtc/rtc-cros-ec.c | 38 +++++++++++++++++++++++---------------
drivers/rtc/rtc-ds1305.c | 3 ++-
drivers/rtc/rtc-rzn1.c | 1 +
drivers/rtc/rtc-tps6586x.c | 1 +
include/linux/rtc.h | 1 +
kernel/time/alarmtimer.c | 13 +++++++++++++
7 files changed, 52 insertions(+), 16 deletions(-)
