linux.git/drivers/rtc/interface.c, branch v4.9.332

rtc: ensure rtc_set_alarm fails when alarms are not supported

2018-08-03T05:55:13+00:00

[ Upstream commit abfdff44bc38e9e2ef7929f633fb8462632299d4 ]

When using RTC_ALM_SET or RTC_WKALM_SET with rtc_wkalrm.enabled not set,
rtc_timer_enqueue() is not called and rtc_set_alarm() may succeed but the
subsequent RTC_AIE_ON ioctl will fail. RTC_ALM_READ would also fail in that
case.

Ensure rtc_set_alarm() fails when alarms are not supported to avoid letting
programs think the alarms are working for a particular RTC when they are
not.

Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

rtc: interface: Validate alarm-time before handling rollover

2018-04-13T17:48:14+00:00

[ Upstream commit da96aea0ed177105cb13ee83b328f6c61e061d3f ]

In function __rtc_read_alarm() its possible for an alarm time-stamp to
be invalid even after replacing missing components with current
time-stamp. The condition 'alarm->time.tm_year < 70' will trigger this
case and will cause the call to 'rtc_tm_to_time64(&alarm->time)'
return a negative value for variable t_alm.

While handling alarm rollover this negative t_alm (assumed to seconds
offset from '1970-01-01 00:00:00') is converted back to rtc_time via
rtc_time64_to_tm() which results in this error log with seemingly
garbage values:

"rtc rtc0: invalid alarm value: -2-1--1041528741
2005511117:71582844:32"

This error was generated when the rtc driver (rtc-opal in this case)
returned an alarm time-stamp of '00-00-00 00:00:00' to indicate that
the alarm is disabled. Though I have submitted a separate fix for the
rtc-opal driver, this issue may potentially impact other
existing/future rtc drivers.

To fix this issue the patch validates the alarm time-stamp just after
filling up the missing datetime components and if rtc_valid_tm() still
reports it to be invalid then bails out of the function without
handling the rollover.

Reported-by: Steve Best 
Signed-off-by: Vaibhav Jain 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

rtc: set the alarm to the next expiring timer

2017-12-25T13:23:46+00:00

[ Upstream commit 74717b28cb32e1ad3c1042cafd76b264c8c0f68d ]

If there is any non expired timer in the queue, the RTC alarm is never set.
This is an issue when adding a timer that expires before the next non
expired timer.

Ensure the RTC alarm is set in that case.

Fixes: 2b2f5ff00f63 ("rtc: interface: ignore expired timers when enqueuing new timers")
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

rtc: fix a typo and reduce three empty lines to one

2016-07-11T21:22:35+00:00

Signed-off-by: Uwe Kleine-König 
Signed-off-by: Alexandre Belloni

rtc: interface: ignore expired timers when enqueuing new timers

2016-06-04T13:43:22+00:00

This patch fixes a RTC wakealarm issue, namely, the event fires during
hibernate and is not cleared from the list, causing hwclock to block.

The current enqueuing does not trigger an alarm if any expired timers
already exist on the timerqueue. This can occur when a RTC wake alarm
is used to wake a machine out of hibernate and the resumed state has
old expired timers that have not been removed from the timer queue.
This fix skips over any expired timers and triggers an alarm if there
are no pending timers on the timerqueue. Note that the skipped expired
timer will get reaped later on, so there is no need to clean it up
immediately.

The issue can be reproduced by putting a machine into hibernate and
waking it with the RTC wakealarm.  Running the example RTC test program
from tools/testing/selftests/timers/rtctest.c after the hibernate will
block indefinitely.  With the fix, it no longer blocks after the
hibernate resume.

BugLink: http://bugs.launchpad.net/bugs/1333569

Signed-off-by: Colin Ian King 
Signed-off-by: Alexandre Belloni

rtc: initialize output parameter for read alarm to "uninitialized"

2016-05-29T23:37:11+00:00

rtc drivers are supposed to set values they don't support to -1. To
simplify this for drivers and also make it harder for them to get it
wrong initialize the values to -1.

Signed-off-by: Uwe Kleine-König 
Signed-off-by: Alexandre Belloni

rtc: Add functions to set and read rtc offset

2016-03-14T16:08:15+00:00

A number of rtc devices, such as the NXP pcf2123 include a facility
to adjust the clock in order to compensate for temperature or a
crystal, capacitor, etc, that results in the rtc clock not running
at exactly 32.768 kHz.

Data sheets I have seen refer to this as a clock offset, and measure it
in parts per million, however they often reference ppm to 2 digits of
precision, which makes integer ppm less than ideal.

We use parts per billion, which more than covers the precision needed
and works nicely within 32 bits

Signed-off-by: Joshua Clayton 
Signed-off-by: Alexandre Belloni

rtc: Drop (un)likely before IS_ERR(_OR_NULL)

2015-09-05T11:19:09+00:00

IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there
is no need to do that again from its callers. Drop it.

gemini driver was using likely() for a failure case while the rtc driver
is getting registered. That looks wrong and it should really be
unlikely. But because we are killing all the unlikely() flags, lets kill
that too.

Signed-off-by: Viresh Kumar 
Acked-by: Hans Ulli Kroll 
Signed-off-by: Alexandre Belloni

rtc: interface: Remove rtc_set_mmss()

2015-06-24T23:13:43+00:00

Now rtc_set_mmss() has no users, just remove it.

We still have rtc_set_time() doing similar things.

Signed-off-by: Xunlei Pang 
Signed-off-by: Alexandre Belloni

rtc: interface: Remove unused return value from rtc_timer_cancel()

2015-06-19T18:03:20+00:00

The rtc_timer_cancel() always returns 0 and cannot fail (calls only
other void-returning functions).

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Alexandre Belloni