linux-stable.git/drivers/rtc, branch v4.1.50

rtc-opal: Fix handling of firmware error codes, prevent busy loops

2018-03-04T15:28:23+00:00

[ Upstream commit 5b8b58063029f02da573120ef4dc9079822e3cda ]

According to the OPAL docs:
  skiboot-5.2.5/doc/opal-api/opal-rtc-read-3.txt
  skiboot-5.2.5/doc/opal-api/opal-rtc-write-4.txt

OPAL_HARDWARE may be returned from OPAL_RTC_READ or OPAL_RTC_WRITE and
this indicates either a transient or permanent error.

Prior to this patch, Linux was not dealing with OPAL_HARDWARE being a
permanent error particularly well, in that you could end up in a busy
loop.

This was not too hard to trigger on an AMI BMC based OpenPOWER machine
doing a continuous "ipmitool mc reset cold" to the BMC, the result of
that being that we'd get stuck in an infinite loop in
opal_get_rtc_time().

We now retry a few times before returning the error higher up the
stack.

Fixes: 16b1d26e77b1 ("rtc/tpo: Driver to support rtc and wakeup on PowerNV platform")
Cc: stable@vger.kernel.org # v3.19+
Signed-off-by: Stewart Smith 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin

rtc: set the alarm to the next expiring timer

2018-03-01T00:32:16+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

rtc: s35390a: improve irq handling

2018-01-17T17:33:22+00:00

[ Upstream commit 3bd32722c827d00eafe8e6d5b83e9f3148ea7c7e ]

On some QNAP NAS devices the rtc can wake the machine. Several people
noticed that once the machine was woken this way it fails to shut down.
That's because the driver fails to acknowledge the interrupt and so it
keeps active and restarts the machine immediatly after shutdown. See
https://bugs.debian.org/794266 for a bug report.

Doing this correctly requires to interpret the INT2 flag of the first read
of the STATUS1 register because this bit is cleared by read.

Note this is not maximally robust though because a pending irq isn't
detected when the STATUS1 register was already read (and so INT2 is not
set) but the irq was not disabled. But that is a hardware imposed problem
that cannot easily be fixed by software.

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

rtc: s35390a: implement reset routine as suggested by the reference

2018-01-17T17:33:17+00:00

[ Upstream commit 8e6583f1b5d1f5f129b873f1428b7e414263d847 ]

There were two deviations from the reference manual: you have to wait
half a second when POC is active and you might have to repeat
initialization when POC or BLD are still set after the sequence.

Note however that as POC and BLD are cleared by read the driver might
not be able to detect that a reset is necessary. I don't have a good
idea how to fix this.

Additionally report the value read from STATUS1 to the caller. This
prepares the next patch.

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

rtc: s35390a: fix reading out alarm

2018-01-17T17:33:12+00:00

[ Upstream commit f87e904ddd8f0ef120e46045b0addeb1cc88354e ]

There are several issues fixed in this patch:

 - When alarm isn't enabled, set .enabled to zero instead of returning
   -EINVAL.
 - Ignore how IRQ1 is configured when determining if IRQ2 is on.
 - The three alarm registers have an enable flag which must be
   evaluated.
 - The chip always triggers when the seconds register gets 0.

Note that the rtc framework however doesn't handle the result correctly
because it doesn't check wday being initialized and so interprets an
alarm being set for 10:00 AM in three days as 10:00 AM tomorrow (or
today if that's not over yet).

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

rtc: interface: ignore expired timers when enqueuing new timers

2018-01-17T17:24:37+00:00

[ Upstream commit 2b2f5ff00f63847d95adad6289bd8b05f5983dd5 ]

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 
Signed-off-by: Sasha Levin

rtc: tegra: Implement clock handling

2017-06-13T13:29:17+00:00

[ Upstream commit 5fa4086987506b2ab8c92f8f99f2295db9918856 ]

Accessing the registers of the RTC block on Tegra requires the module
clock to be enabled. This only works because the RTC module clock will
be enabled by default during early boot. However, because the clock is
unused, the CCF will disable it at late_init time. This causes the RTC
to become unusable afterwards. This can easily be reproduced by trying
to use the RTC:

	$ hwclock --rtc /dev/rtc1

This will hang the system. I ran into this by following up on a report
by Martin Michlmayr that reboot wasn't working on Tegra210 systems. It
turns out that the rtc-tegra driver's ->shutdown() implementation will
hang the CPU, because of the disabled clock, before the system can be
rebooted.

What confused me for a while is that the same driver is used on prior
Tegra generations where the hang can not be observed. However, as Peter
De Schrijver pointed out, this is because on 32-bit Tegra chips the RTC
clock is enabled by the tegra20_timer.c clocksource driver, which uses
the RTC to provide a persistent clock. This code is never enabled on
64-bit Tegra because the persistent clock infrastructure does not exist
on 64-bit ARM.

The proper fix for this is to add proper clock handling to the RTC
driver in order to ensure that the clock is enabled when the driver
requires it. All device trees contain the clock already, therefore
no additional changes are required.

Reported-by: Martin Michlmayr 
Acked-By Peter De Schrijver 
Signed-off-by: Thierry Reding 
Signed-off-by: Alexandre Belloni 

Signed-off-by: Sasha Levin

rtc: sun6i: Switch to the external oscillator

2017-05-17T19:06:58+00:00

[ Upstream commit fb61bb82cb46a932ef2fc62e1c731c8e7e6640d5 ]

The RTC is clocked from either an internal, imprecise, oscillator or an
external one, which is usually much more accurate.

The difference perceived between the time elapsed and the time reported by
the RTC is in a 10% scale, which prevents the RTC from being useful at all.

Fortunately, the external oscillator is reported to be mandatory in the
Allwinner datasheet, so we can just switch to it.

Cc: stable@vger.kernel.org
Fixes: 9765d2d94309 ("rtc: sun6i: Add sun6i RTC driver")
Signed-off-by: Maxime Ripard 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin

rtc: sun6i: Add some locking

2017-05-17T19:06:58+00:00

[ Upstream commit a9422a19ce270a22fc520f2278fb7e80c58be508 ]

Some registers have a read-modify-write access pattern that are not atomic.

Add some locking to prevent from concurrent accesses.

Cc: stable@vger.kernel.org
Acked-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin

rtc: s3c: Add s3c_rtc_{enable/disable}_clk in s3c_rtc_setfreq()

2016-08-20T03:07:58+00:00

[ Upstream commit 70c96dfac0e231424e17743bd52f6cd2ff1f2439 ]

As per code flow s3c_rtc_setfreq() will get called with rtc clock disabled
and in set_freq we perform h/w registers read/write, which results in a
kernel crash on exynos7 platform while probing rtc driver.
Below is code flow:
s3c_rtc_probe()
    clk_prepare_enable(info->rtc_clk) // rtc clock enabled
    s3c_rtc_gettime() // will enable clk if not done, and disable it upon exit
    s3c_rtc_setfreq() //then this will be called with clk disabled

This patch take cares of such issue by adding s3c_rtc_{enable/disable}_clk in
s3c_rtc_setfreq().

Fixes: 24e1455493da ("drivers/rtc/rtc-s3c.c: delete duplicate clock control")

Cc: 
Signed-off-by: Alim Akhtar 
Reviewed-by: Krzysztof Kozlowski 
Reviewed-by: Pankaj Dubey 
Tested-by: Pankaj Dubey 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin