linux-toradex.git/drivers/rtc, branch v4.4.153

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

rtc: hctosys: Ensure system time doesn't overflow time_t

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

[ Upstream commit b3a5ac42ab18b7d1a8f2f072ca0ee76a3b754a43 ]

On 32bit platforms, time_t is still a signed 32bit long. If it is
overflowed, userspace and the kernel cant agree on the current system time.
This causes multiple issues, in particular with systemd:
https://github.com/systemd/systemd/issues/1143

A good workaround is to simply avoid using hctosys which is something I
greatly encourage as the time is better set by userspace.

However, many distribution enable it and use systemd which is rendering the
system unusable in case the RTC holds a date after 2038 (and more so after
2106). Many drivers have workaround for this case and they should be
eliminated so there is only one place left to fix when userspace is able to
cope with dates after the 31bit overflow.

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

rtc: snvs: Fix usage of snvs_rtc_enable

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

[ Upstream commit 1485991c024603b2fb4ae77beb7a0d741128a48e ]

commit 179a502f8c46 ("rtc: snvs: add Freescale rtc-snvs driver") introduces
the SNVS RTC driver with a function snvs_rtc_enable().

snvs_rtc_enable() can return an error on the enable path however this
driver does not currently trap that failure on the probe() path and
consequently if enabling the RTC fails we encounter a later error spinning
forever in rtc_write_sync_lp().

[   36.093481] [] (__irq_svc) from [] (_raw_spin_unlock_irqrestore+0x34/0x44)
[   36.102122] [] (_raw_spin_unlock_irqrestore) from [] (regmap_read+0x4c/0x5c)
[   36.110938] [] (regmap_read) from [] (rtc_write_sync_lp+0x6c/0x98)
[   36.118881] [] (rtc_write_sync_lp) from [] (snvs_rtc_alarm_irq_enable+0x40/0x4c)
[   36.128041] [] (snvs_rtc_alarm_irq_enable) from [] (rtc_timer_do_work+0xd8/0x1a8)
[   36.137291] [] (rtc_timer_do_work) from [] (process_one_work+0x28c/0x76c)
[   36.145840] [] (process_one_work) from [] (worker_thread+0x34/0x58c)
[   36.153961] [] (worker_thread) from [] (kthread+0x138/0x150)
[   36.161388] [] (kthread) from [] (ret_from_fork+0x14/0x20)
[   36.168635] rcu_sched kthread starved for 2602 jiffies! g496 c495 f0x2 RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0
[   36.178564] rcu_sched       R  running task        0     8      2 0x00000000
[   36.185664] [] (__schedule) from [] (schedule+0x3c/0xa0)
[   36.192739] [] (schedule) from [] (schedule_timeout+0x78/0x4e0)
[   36.200422] [] (schedule_timeout) from [] (rcu_gp_kthread+0x648/0x1864)
[   36.208800] [] (rcu_gp_kthread) from [] (kthread+0x138/0x150)
[   36.216309] [] (kthread) from [] (ret_from_fork+0x14/0x20)

This patch fixes by parsing the result of rtc_write_sync_lp() and
propagating both in the probe and elsewhere. If the RTC doesn't start we
don't proceed loading the driver and don't get into this loop mess later
on.

Fixes: 179a502f8c46 ("rtc: snvs: add Freescale rtc-snvs driver")
Signed-off-by: Bryan O'Donoghue 
Acked-by: Shawn Guo 
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:50:15+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: opal: Handle disabled TPO in opal_get_tpo_time()

2018-04-13T17:50:15+00:00

[ Upstream commit 6dc1cf6f932bb0ea4d8f5e913a0a401ecacd2f03 ]

On PowerNV platform when Timed-Power-On(TPO) is disabled, read of
stored TPO yields value with all date components set to '0' inside
opal_get_tpo_time(). The function opal_to_tm() then converts it to an
offset from year 1900 yielding alarm-time == "1900-00-01
00:00:00". This causes problems with __rtc_read_alarm() that
expecting an offset from "1970-00-01 00:00:00" and returned alarm-time
results in a -ve value for time64_t. Which ultimately results in this
error reported in kernel logs with a seemingly garbage value:

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

We fix this by explicitly handling the case of all alarm date-time
components being '0' inside opal_get_tpo_time() and returning -ENOENT
in such a case. This signals generic rtc that no alarm is set and it
bails out from the alarm initialization flow without reporting the
above error.

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

rtc: snvs: fix an incorrect check of return value

2018-04-13T17:50:01+00:00

[ Upstream commit 758929005f06f954b7e1c87a1c9fdb44157b228f ]

Function devm_regmap_init_mmio() returns an ERR_PTR on error. However,
in function snvs_rtc_probe() its return value is checked against NULL.
This patch fixes it by checking the return value with IS_ERR().

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

rtc: ds1374: wdt: Fix stop/start ioctl always returning -EINVAL

2018-03-24T09:58:46+00:00

[ Upstream commit 538c08f4c89580fc644e2bc64e0a4b86c925da4e ]

The WDIOC_SETOPTIONS case in the watchdog ioctl would alwayss falls
through to the -EINVAL case. This is wrong since thew watchdog does
actually get stopped or started correctly.

Fixes: 920f91e50c5b ("drivers/rtc/rtc-ds1374.c: add watchdog support")
Signed-off-by: Moritz Fischer 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

rtc: ds1374: wdt: Fix issue with timeout scaling from secs to wdt ticks

2018-03-24T09:58:46+00:00

[ Upstream commit 453d0744f6c6ca3f9749b8c57c2e85b5b9f52514 ]

The issue is that the internal counter that triggers the watchdog reset
is actually running at 4096 Hz instead of 1Hz, therefore the value
given by userland (in sec) needs to be multiplied by 4096 to get the
correct behavior.

Fixes: 920f91e50c5b ("drivers/rtc/rtc-ds1374.c: add watchdog support")
Signed-off-by: Moritz Fischer 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

rtc: cmos: Do not assume irq 8 for rtc when there are no legacy irqs

2018-03-24T09:58:40+00:00

[ Upstream commit a1e23a42f1bdc00e32fc4869caef12e4e6272f26 ]

On some systems (e.g. Intel Bay Trail systems) the legacy PIC is not
used, in this case virq 8 will be a random irq, rather then hw_irq 8
from the PIC.

Requesting virq 8 in this case will not help us to get alarm irqs and
may cause problems for other drivers which actually do need virq 8,
for example on an Asus Transformer T100TA this leads to:

[ 28.745155] genirq: Flags mismatch irq 8. 00000088 (mmc0) vs. 00000080 (rtc0)

[ 28.753700] mmc0: Failed to request IRQ 8: -16
[ 28.975934] sdhci-acpi: probe of 80860F14:01 failed with error -16

This commit fixes this by making the rtc-cmos driver continue
without using an irq rather then claiming irq 8 when no irq is
specified in the pnp-info and there are no legacy-irqs.

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