linux.git/drivers/rtc, branch v3.12.50

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

rtc: rtc-at91rm9200: fix infinite wait for ACKUPD irq

2014-06-23T08:27:53+00:00

commit 2fe121e1f5aa3bf31b418a9790db6c400e922291 upstream.

The rtc user must wait at least 1 sec between each time/calandar update
(see atmel's datasheet chapter "Updating Time/Calendar").

Use the 1Hz interrupt to update the at91_rtc_upd_rdy flag and wait for
the at91_rtc_wait_upd_rdy event if the rtc is not ready.

This patch fixes a deadlock in an uninterruptible wait when the RTC is
updated more than once every second.  AFAICT the bug is here from the
beginning, but I think we should at least backport this fix to 3.10 and
the following longterm and stable releases.

Signed-off-by: Boris BREZILLON 
Reported-by: Bryan Evenson 
Tested-by: Bryan Evenson 
Cc: Andrew Victor 
Cc: Nicolas Ferre 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Alessandro Zummo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jiri Slaby

rtc-cmos: Add an alarm disable quirk

2014-02-13T21:50:26+00:00

commit d5a1c7e3fc38d9c7d629e1e47f32f863acbdec3d upstream.

41c7f7424259f ("rtc: Disable the alarm in the hardware (v2)") added the
functionality to disable the RTC wake alarm when shutting down the box.

However, there are at least two b0rked BIOSes we know about:

https://bugzilla.novell.com/show_bug.cgi?id=812592
https://bugzilla.novell.com/show_bug.cgi?id=805740

where, when wakeup alarm is enabled in the BIOS, the machine reboots
automatically right after shutdown, regardless of what wakeup time is
programmed.

Bisecting the issue lead to this patch so disable its functionality with
a DMI quirk only for those boxes.

Cc: Brecht Machiels 
Cc: Thomas Gleixner 
Cc: John Stultz 
Cc: Rabin Vincent 
Signed-off-by: Borislav Petkov 
[jstultz: Changed variable name for clarity, added extra dmi entry]
Tested-by: Brecht Machiels 
Tested-by: Borislav Petkov 
Signed-off-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman

rtc: max8907: weekday encoding fixes

2014-02-06T19:22:18+00:00

commit 75ea799df4cb07e505c91b4abaa87bc28aad3e66 upstream.

The current MAX8907 driver has two issues related to weekday value
handling:

1)

The HW WEEKDAY register has range 0..6 rather than 1..7 as documented.
Note that I validated the actual HW range by observing the HW register
roll from 6->0 rather than 6->7->1 as would otherwise be expected.

This matches Linux's tm_wday range of 0..6.

When the CMOS RAM content is lost, the date returned from the device is
2007-01-01 00:00:00, which is a Monday.  The WEEKDAY register reads 1 in
this case.  This matches the numbering in Linux's tm_wday field.

Hence we should write Linux's tm_wday value to the register without
modifying it.  Hence, remove the +1/-1 calculations for WEEKDAY/tm_wday.

2)

There's no need to make alarms match on the WEEKDAY register, since the
other fields together uniquely define the alarm date/time.  Ignoring the
WEEKDAY value in the match isolates the driver from any incorrect value in
the current time copy of the WEEKDAY register.

Each change individually, or both together, solves an issue that I
observed; "hwclock -r" would time out waiting for its alarm to fire if the
CMOS RAM content had been lost, and hence the WEEKDAY register value
mismatched what the driver expected it to be.  "hwclock -w" would solve
this by over-writing the HW default WEEKDAY register value with what the
driver expected.

Signed-off-by: Stephen Warren 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

drivers/rtc/rtc-at91rm9200.c: correct alarm over day/month wrap

2013-12-20T15:48:56+00:00

commit eb3c227289840eed95ddfb0516046f08d8993940 upstream.

Update month and day of month to the alarm month/day instead of current
day/month when setting the RTC alarm mask.

Signed-off-by: Linus Pizunski 
Signed-off-by: Nicolas Ferre 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

rtc: simplify devm_request_mem_region/devm_ioremap

2013-09-11T22:58:59+00:00

Convert the composition of devm_request_mem_region and devm_ioremap to a
single call to devm_ioremap_resource.  The associated call to
platform_get_resource is also simplified and moved next to the new call
to devm_ioremap_resource.

This was done using a combination of the semantic patches
devm_ioremap_resource.cocci and devm_request_and_ioremap.cocci, found in
the scripts/coccinelle/api directory.

In rtc-lpc32xx.c and rtc-mv.c, the local variable size is no longer needed.

In rtc-ds1511.c the size field of the local structure is not useful any
more, and is deleted.

Signed-off-by: Julia Lawall 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

drivers/rtc/rtc-ds1742.c: report to RTC core if retrieved time is invalid

2013-09-11T22:58:58+00:00

Let RTC core decide if the retrieved time is invalid, instead of
processing errors in the driver.

Signed-off-by: Alexander Shiyan 
Cc: Jingoo Han 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds