linux.git/drivers/rtc, branch v4.4.187

rtc: 88pm860x: prevent use-after-free on device remove

2019-06-11T10:23:54+00:00

[ Upstream commit f22b1ba15ee5785aa028384ebf77dd39e8e47b70 ]

The device's remove() attempts to shut down the delayed_work scheduled
on the kernel-global workqueue by calling flush_scheduled_work().

Unfortunately, flush_scheduled_work() does not prevent the delayed_work
from re-scheduling itself. The delayed_work might run after the device
has been removed, and touch the already de-allocated info structure.
This is a potential use-after-free.

Fix by calling cancel_delayed_work_sync() during remove(): this ensures
that the delayed work is properly cancelled, is no longer running, and
is not able to re-schedule itself.

This issue was detected with the help of Coccinelle.

Signed-off-by: Sven Van Asbroeck 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin

rtc: da9063: set uie_unsupported when relevant

2019-05-16T17:45:01+00:00

[ Upstream commit 882c5e552ffd06856de42261460f46e18319d259 ]

The DA9063AD doesn't support alarms on any seconds and its granularity is
the minute. Set uie_unsupported in that case.

Reported-by: Wolfram Sang 
Reported-by: Geert Uytterhoeven 
Reviewed-by: Wolfram Sang 
Tested-by: Wolfram Sang 
Acked-by: Steve Twiss 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin

rtc: sh: Fix invalid alarm warning for non-enabled alarm

2019-05-16T17:45:00+00:00

[ Upstream commit 15d82d22498784966df8e4696174a16b02cc1052 ]

When no alarm has been programmed on RSK-RZA1, an error message is
printed during boot:

    rtc rtc0: invalid alarm value: 2019-03-14T255:255:255

sh_rtc_read_alarm_value() returns 0xff when querying a hardware alarm
field that is not enabled.  __rtc_read_alarm() validates the received
alarm values, and fills in missing fields when needed.
While 0xff is handled fine for the year, month, and day fields, and
corrected as considered being out-of-range, this is not the case for the
hour, minute, and second fields, where -1 is expected for missing
fields.

Fix this by returning -1 instead, as this value is handled fine for all
fields.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin

rtc: Fix overflow when converting time64_t to rtc_time

2019-04-03T04:23:19+00:00

commit 36d46cdb43efea74043e29e2a62b13e9aca31452 upstream.

If we convert one large time values to rtc_time, in the original formula
'days * 86400' can be overflowed in 'unsigned int' type to make the formula
get one incorrect remain seconds value. Thus we can use div_s64_rem()
function to avoid this situation.

Signed-off-by: Baolin Wang 
Acked-by: Arnd Bergmann 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

rtc: snvs: Add timeouts to avoid kernel lockups

2018-12-21T13:09:53+00:00

[ Upstream commit cd7f3a249dbed2858e6c2f30e5be7f1f7a709ee2 ]

In order to read correctly from asynchronously updated RTC registers,
it's necessary to read repeatedly until their values do not change from
read to read.  It's also necessary to wait for three RTC clock ticks for
certain operations.  There are no timeouts in this code and these
operations could possibly loop forever.

To avoid kernel hangs, put in timeouts.

The iMX7d can be configured to stop the SRTC on a tamper event, which
will lockup the kernel inside this driver as described above.

These hangs can happen when running under qemu, which doesn't emulate
the SNVS RTC, though currently the driver will refuse to load on qemu
due to a timeout in the driver probe method.

It could also happen if the SRTC block where somehow placed into reset
or the slow speed clock that drives the SRTC counter (but not the CPU)
were to stop.

The symptoms on a two core iMX7d are a work queue hang on
rtc_timer_do_work(), which eventually blocks a systemd fsnotify
operation that triggers a work queue flush, causing systemd to hang and
thus causing all services that should be started by systemd, like a
console getty, to fail to start or stop.

Also optimize the wait code to wait less.  It only needs to wait for the
clock to advance three ticks, not to see it change three times.

Cc: Alexandre Belloni 
Cc: Alessandro Zummo 
Cc: Fabio Estevam 
Cc: Shawn Guo 
Cc: Bryan O'Donoghue 
Signed-off-by: Trent Piepho 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin

rtc: snvs: add a missing write sync

2018-12-21T13:09:53+00:00

[ Upstream commit 7bb633b1a9812a6b9f3e49d0cf17f60a633914e5 ]

The clear of the LPTA_EN flag should be synced before writing to the
alarm register. Omitting this synchronization creates a race when
trying to change existing alarm.

Signed-off-by: Guy Shapiro 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin

rtc: hctosys: Add missing range error reporting

2018-11-21T08:27:44+00:00

commit 7ce9a992ffde8ce93d5ae5767362a5c7389ae895 upstream.

Fix an issue with the 32-bit range error path in `rtc_hctosys' where no
error code is set and consequently the successful preceding call result
from `rtc_read_time' is propagated to `rtc_hctosys_ret'.  This in turn
makes any subsequent call to `hctosys_show' incorrectly report in sysfs
that the system time has been set from this RTC while it has not.

Set the error to ERANGE then if we can't express the result due to an
overflow.

Signed-off-by: Maciej W. Rozycki 
Fixes: b3a5ac42ab18 ("rtc: hctosys: Ensure system time doesn't overflow time_t")
Cc: stable@vger.kernel.org # 4.17+
Signed-off-by: Alexandre Belloni 
Signed-off-by: Greg Kroah-Hartman

rtc: bq4802: add error handling for devm_ioremap

2018-09-26T06:35:09+00:00

[ Upstream commit 7874b919866ba91bac253fa219d3d4c82bb944df ]

When devm_ioremap fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling devm_ioremap.

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

rtc: ensure rtc_set_alarm fails when alarms are not supported

2018-08-06T14:24:30+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: tx4939: avoid unintended sign extension on a 24 bit shift

2018-05-30T05:49:14+00:00

[ Upstream commit 347876ad47b9923ce26e686173bbf46581802ffa ]

The shifting of buf[5] by 24 bits to the left will be promoted to
a 32 bit signed int and then sign-extended to an unsigned long. If
the top bit of buf[5] is set then all then all the upper bits sec
end up as also being set because of the sign-extension. Fix this by
casting buf[5] to an unsigned long before the shift.

Detected by CoverityScan, CID#1465292 ("Unintended sign extension")

Fixes: 0e1492330cd2 ("rtc: add rtc-tx4939 driver")
Signed-off-by: Colin Ian King 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman