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

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

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

2018-02-22T14:44:59+00:00

commit 5b8b58063029f02da573120ef4dc9079822e3cda upstream.

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: Greg Kroah-Hartman

rtc: set the alarm to the next expiring timer

2017-12-25T13:22:15+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: pl031: make interrupt optional

2017-12-25T13:22:14+00:00

[ Upstream commit 5b64a2965dfdfca8039e93303c64e2b15c19ff0c ]

On some platforms, the interrupt for the PL031 is optional.  Avoid
trying to claim the interrupt if it's not specified.

Reviewed-by: Linus Walleij 
Signed-off-by: Russell King 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

rtc: pcf8563: fix output clock rate

2017-12-20T09:04:57+00:00

[ Upstream commit a3350f9c57ffad569c40f7320b89da1f3061c5bb ]

The pcf8563_clkout_recalc_rate function erroneously ignores the
frequency index read from the CLKO register and always returns
32768 Hz.

Fixes: a39a6405d5f9 ("rtc: pcf8563: add CLKOUT to common clock framework")
Signed-off-by: Philipp Zabel 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

rtc: tegra: Implement clock handling

2017-04-21T07:30:07+00:00

commit 5fa4086987506b2ab8c92f8f99f2295db9918856 upstream.

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 
[bwh: Backported to 4.9: adjust context]
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

rtc: s35390a: improve irq handling

2017-04-08T07:53:32+00:00

commit 3bd32722c827d00eafe8e6d5b83e9f3148ea7c7e upstream.

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: Greg Kroah-Hartman

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

2017-04-08T07:53:32+00:00

commit 8e6583f1b5d1f5f129b873f1428b7e414263d847 upstream.

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: Greg Kroah-Hartman