linux-stable.git/drivers/rtc, branch linux-3.12.y

rtc: s35390a: improve irq handling

2017-04-10T13:09:46+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: Jiri Slaby

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

2017-04-10T13:09:45+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: Jiri Slaby

rtc: s35390a: make sure all members in the output are set

2017-04-10T13:09:45+00:00

The rtc core calls the .read_alarm with all fields initialized to 0. As
the s35390a driver doesn't touch some fields the returned date is
interpreted as a date in January 1900. So make sure all fields are set
to -1; some of them are then overwritten with the right data depending
on the hardware state.

In mainline this is done by commit d68778b80dd7 ("rtc: initialize output
parameter for read alarm to "uninitialized"") in the core. This is
considered to dangerous for stable as it might have side effects for
other rtc drivers that might for example rely on alarm->time.tm_sec
being initialized to 0.

Signed-off-by: Uwe Kleine-König 
Signed-off-by: Jiri Slaby

rtc: s35390a: fix reading out alarm

2017-04-10T13:09:44+00:00

commit f87e904ddd8f0ef120e46045b0addeb1cc88354e upstream.

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: Jiri Slaby

rtc: interface: ignore expired timers when enqueuing new timers

2017-03-01T19:10:26+00:00

commit 2b2f5ff00f63847d95adad6289bd8b05f5983dd5 upstream.

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 
Cc: Sumit Semwal 
Signed-off-by: Jiri Slaby

rtc: vr41xx: Wire up alarm_irq_enable

2016-05-03T05:45:08+00:00

commit a25f4a95ec3cded34c1250364eba704c5e4fdac4 upstream.

drivers/rtc/rtc-vr41xx.c:229: warning: ‘vr41xx_rtc_alarm_irq_enable’ defined but not used

Apparently the conversion to alarm_irq_enable forgot to wire up the
callback.

Fixes: 16380c153a69c378 ("RTC: Convert rtc drivers to use the alarm_irq_enable method")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Jiri Slaby

drivers/rtc/rtc-sirfsoc.c: move hardware initilization earlier in probe

2015-01-14T13:42:50+00:00

commit 0e95325525c4383565cea4f402f15a3113162d05 upstream.

Move rtc register to be later than hardware initialization.  The reason
is that devm_rtc_device_register() will do read_time() which is a
callback accessing hardware.  This sometimes causes a hang in the
hardware related callback.

Signed-off-by: Guo Zeng 
Signed-off-by: Barry Song 
Cc: Alessandro Zummo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jiri Slaby

drivers/rtc/interface.c: fix infinite loop in initializing the alarm

2014-08-26T12:12:25+00:00

commit ee1d90146815fdc8d653c558b327fff2acba041d upstream.

In __rtc_read_alarm(), if the alarm time retrieved by
rtc_read_alarm_internal() from the device contains invalid values (e.g.
month=2,mday=31) and the year not set (=-1), the initialization will
loop infinitely because the year-fixing loop expects the time being
invalid due to leap year.

Fix reduces the loop to the leap years and adds final validity check.

Signed-off-by: Ales Novak 
Acked-by: Alessandro Zummo 
Reported-by: Jiri Bohac 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jiri Slaby

drivers/rtc/rtc-efi.c: check for invalid data coming back from UEFI

2014-08-26T12:12:25+00:00

commit 6e85bab6bc1019f9b87c53b32da3ad7791e7ddf9 upstream.

In particular seeing zero in eft->month is problematic, as it results in
-1 (converted to unsigned int, i.e.  yielding 0xffffffff) getting passed
to rtc_year_days(), where the value gets used as an array index
(normally resulting in a crash).  This was observed with the driver
enabled on x86 on some Fujitsu system (with possibly not up to date
firmware, but anyway).

Perhaps efi_read_alarm() should not fail if neither enabled nor pending
are set, but the returned time is invalid?

Signed-off-by: Jan Beulich 
Reported-by: Raymund Will 
Cc: Alessandro Zummo 
Cc: Jingoo Han 
Acked-by: Lee, Chun-Yi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jiri Slaby

drivers/rtc/rtc-efi.c: avoid subtracting day twice when computing year days

2014-08-26T12:12:24+00:00

commit 809d9627087e1db63b8672c1f264af73b13116fb upstream.

Compared source code of rtc-lib.c::rtc_year_days() with
efirtc.c::rtc_year_days(), found the code in rtc-efi decreases value of
day twice when it computing year days.  rtc-lib.c::rtc_year_days() has
already decrease days and return the year days from 0 to 365.

Signed-off-by: Lee, Chun-Yi 
Cc: Alessandro Zummo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jiri Slaby