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

rtc-cmos: Add an alarm disable quirk

2014-02-13T21:55:46+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:34:01+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

mfd/rtc: s5m: fix register updating by adding regmap for RTC

2013-12-13T02:19:26+00:00

Rename old regmap field of "struct sec_pmic_dev" to "regmap_pmic" and
add new regmap for RTC.

On S5M8767A registers were not properly updated and read due to usage of
the same regmap as the PMIC.  This could be observed in various hangs,
e.g.  in infinite loop during waiting for UDR field change.

On this chip family the RTC has different I2C address than PMIC so
additional regmap is needed.

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Kyungmin Park 
Reviewed-by: Mark Brown 
Acked-by: Sangbeom Kim 
Cc: Samuel Ortiz 
Cc: Lee Jones 
Cc: Liam Girdwood 
Cc: Alessandro Zummo 
Cc: Marek Szyprowski 
Cc: Geert Uytterhoeven 
Cc: Kyungmin Park 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc: s5m: enable IRQ wake during suspend

2013-12-13T02:19:26+00:00

Add PM suspend/resume ops to rtc-s5m driver and enable IRQ wake during
suspend so the RTC would act like a wake up source.  This allows waking
up from suspend to RAM on RTC alarm interrupt.

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Kyungmin Park 
Cc: Mark Brown 
Acked-by: Sangbeom Kim 
Cc: Samuel Ortiz 
Cc: Lee Jones 
Cc: Liam Girdwood 
Cc: Alessandro Zummo 
Cc: Marek Szyprowski 
Cc: Geert Uytterhoeven 
Cc: Kyungmin Park 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc: s5m: limit endless loop waiting for register update

2013-12-13T02:19:26+00:00

After setting alarm or time the driver is waiting for UDR register to be
cleared indicating that registers data have been transferred.

Limit the endless loop to only 5 retries.

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Kyungmin Park 
Reviewed-by: Mark Brown 
Acked-by: Sangbeom Kim 
Cc: Samuel Ortiz 
Cc: Lee Jones 
Cc: Liam Girdwood 
Cc: Alessandro Zummo 
Cc: Marek Szyprowski 
Cc: Geert Uytterhoeven 
Cc: Kyungmin Park 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc: s5m: fix unsuccesful IRQ request during probe

2013-12-13T02:19:26+00:00

Probe failed for rtc-s5m:

	s5m-rtc s5m-rtc: Failed to request alarm IRQ: 12: -22
	s5m-rtc: probe of s5m-rtc failed with error -22

Fix rtc-s5m interrupt request by using regmap_irq_get_virq() for mapping
the IRQ.

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Kyungmin Park 
Reviewed-by: Mark Brown 
Acked-by: Sangbeom Kim 
Cc: Samuel Ortiz 
Cc: Lee Jones 
Cc: Liam Girdwood 
Cc: Alessandro Zummo 
Cc: Marek Szyprowski 
Cc: Geert Uytterhoeven 
Cc: Kyungmin Park 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

drivers/rtc/rtc-s5m.c: fix info->rtc assignment

2013-12-13T02:19:26+00:00

Fix this warning:

  drivers/rtc/rtc-s5m.c: In function `s5m_rtc_probe':
  drivers/rtc/rtc-s5m.c:545: warning: assignment from incompatible pointer type

struct s5m_rtc_info.rtc has type "struct regmap *", while
struct sec_pmic_dev.rtc has type "struct i2c_client *".

Probably the author wanted to assign "struct sec_pmic_dev.regmap", which
has the correct type.

Also, as "rtc" doesn't make much sense as a name for a regmap, rename it
to "regmap".

Signed-off-by: Geert Uytterhoeven 
Cc: Sangbeom Kim 
Cc: Sachin Kamat 
Tested-by: Krzysztof Kozlowski 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

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

2013-12-13T02:19:26+00:00

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 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

ARM: drivers/rtc/rtc-at91rm9200.c: disable interrupts at shutdown

2013-11-22T00:42:27+00:00

Make sure RTC-interrupts are disabled at shutdown.

As the RTC is generally powered by backup power (VDDBU), its interrupts
are not disabled on wake-up, user, watchdog or software reset.  This
could cause troubles on other systems (e.g.  older kernels) if an
interrupt occurs before a handler has been installed at next boot.

Let us be well-behaved and disable them on clean shutdowns at least (as
do the RTT-based rtc-at91sam9 driver).

Signed-off-by: Johan Hovold 
Acked-by: Nicolas Ferre 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Andrew Victor 
Cc: Alessandro Zummo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

alpha: Reorganize rtc handling

2013-11-17T00:33:16+00:00

Discontinue use of GENERIC_CMOS_UPDATE; rely on the RTC subsystem.

The marvel platform requires that the rtc only be touched from the
boot cpu.  This had been partially implemented with hooks for
get/set_rtc_time, but read/update_persistent_clock were not handled.
Move the hooks from the machine_vec to a special rtc_class_ops struct.

We had read_persistent_clock managing the epoch against which the
rtc hw is based, but this didn't apply to get_rtc_time or set_rtc_time.
This resulted in incorrect values when hwclock(8) gets involved.

Allow the epoch to be set from the kernel command-line, overriding
the autodetection, which is doomed to fail in 2020.  Further, by
implementing the rtc ioctl function, we can expose this epoch to
userland.

Elide the alarm functions that RTC_DRV_CMOS implements.  This was
highly questionable on Alpha, since the interrupt is used by the
system timer.

Signed-off-by: Richard Henderson