fix this bug:
Unable to handle kernel paging request at virtual address 00020008
pgd = d3e60000
[00020008] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP
CPU: 1 Tainted: G C (3.0.36+ #6)
PC is at print_lock_stat+0x1c/0x1b8
LR is at wakelock_stats_show+0x3c/0xa4
or this bug:
WARNING: at lib/list_debug.c:26 __list_add+0x60/0x90()
list_add corruption. next->prev should be prev (c0ae4468), but was 05900000. (next=d89bb060).
[<c043ece0>] (unwind_backtrace+0x0/0xfc) from [<c046dacc>] (warn_slowpath_common+0x4c/0x64)
[<c046dacc>] (warn_slowpath_common+0x4c/0x64) from [<c046db78>] (warn_slowpath_fmt+0x30/0x40)
[<c046db78>] (warn_slowpath_fmt+0x30/0x40) from [<c060554c>] (__list_add+0x60/0x90)
[<c060554c>] (__list_add+0x60/0x90) from [<c04a6140>] (wake_lock_init+0x8c/0xe4)
[<c04a6140>] (wake_lock_init+0x8c/0xe4) from [<c071bda0>] (power_supply_register+0xd8/0x100)
[<c071bda0>] (power_supply_register+0xd8/0x100) from [<c041e5d8>] (test_power_init+0x18/0x7c)
[<c041e5d8>] (test_power_init+0x18/0x7c) from [<c04335d0>] (do_one_initcall+0x34/0x17c)
[<c04335d0>] (do_one_initcall+0x34/0x17c) from [<c0408370>] (kernel_init+0x98/0x144)
[<c0408370>] (kernel_init+0x98/0x144) from [<c0439f64>] (kernel_thread_exit+0x0/0x8)
commit 2f90b68309 upstream.
tm_mon is 0..11, whereas vt8500 expects 1..12 for the month field,
causing invalid date errors for January, and causing the day field to
roll over incorrectly.
The century flag is only handled in vt8500_rtc_read_time, but not set in
vt8500_rtc_set_time. This patch corrects the behaviour of the century
flag.
Signed-off-by: Edgar Toernig <froese@gmx.de>
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7dbfb315b2 upstream.
Correct the offset by subtracting 20 from tm_hour before taking the
modulo 12.
[ "Why 20?" I hear you ask. Or at least I did.
Here's the reason why: RS5C348_BIT_PM is 32, and is - stupidly -
included in the RS5C348_HOURS_MASK define. So it's really subtracting
out that bit to get "hour+12". But then because it does things modulo
12, it needs to add the 12 in again afterwards anyway.
This code is confused. It would be much clearer if RS5C348_HOURS_MASK
just didn't include the RS5C348_BIT_PM bit at all, then it wouldn't
need to do the silly subtract either.
Whatever. It's all just math, the end result is the same. - Linus ]
Reported-by: James Nute <newten82@gmail.com>
Tested-by: James Nute <newten82@gmail.com>
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8dcebaa9a0 upstream.
On some platforms, bootloaders are known to do some interesting RTC
programming. Without going into the obscurities as to why this may be
the case, suffice it to say the the driver should not make any
assumptions about the state of the RTC when the driver loads. In
particular, the driver probe should be sure that all interrupts are
disabled until otherwise programmed.
This was discovered when finding bursty I2C traffic every second on
Overo platforms. This I2C overhead was keeping the SoC from hitting
deep power states. The cause was found to be the RTC firing every
second on the I2C-connected TWL PMIC.
Special thanks to Felipe Balbi for suggesting to look for a rogue driver
as the source of the I2C traffic rather than the I2C driver itself.
Special thanks to Steve Sakoman for helping track down the source of the
continuous RTC interrups on the Overo boards.
Signed-off-by: Kevin Hilman <khilman@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Tested-by: Steve Sakoman <steve@sakoman.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Tested-by: Shubhrajyoti Datta <omaplinuxkernel@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9dccf55f4c upstream.
The tamper evident features of the RTC include the "write counter" which
is a pseudo-random number regenerated whenever we set the RTC. Since this
value is unpredictable it should provide some useful seeding to the random
number generator.
Only do this on boot since the goal is to seed the pool rather than add
useful entropy.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
