[PATCH v2 0/7] rtc: Add support for limited alarm timer offsets

[Guenter Roeck]

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
alarm_offset_max 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

v2:
- Rename range_max_offset -> alarm_offset_max
- Use the new variable to validate the limit where possible

----------------------------------------------------------------
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   |  5 +++--
 drivers/rtc/rtc-rzn1.c     |  3 ++-
 drivers/rtc/rtc-tps6586x.c |  1 +
 include/linux/rtc.h        |  1 +
 kernel/time/alarmtimer.c   | 13 +++++++++++++
 7 files changed, 54 insertions(+), 18 deletions(-)