diff options
author | Zoran Markovic <zoran.markovic@linaro.org> | 2013-05-17 20:24:05 +0200 |
---|---|---|
committer | John Stultz <john.stultz@linaro.org> | 2013-05-28 22:45:19 +0200 |
commit | 0d6bd9953f739dad96d9a0de65383e479ab4e10d (patch) | |
tree | 0f053972369289c5368f67af03a420b8c725828d /drivers | |
parent | ntp: Remove unused variable flags in __hardpps (diff) | |
download | linux-0d6bd9953f739dad96d9a0de65383e479ab4e10d.tar.xz linux-0d6bd9953f739dad96d9a0de65383e479ab4e10d.zip |
timekeeping: Correct run-time detection of persistent_clock.
Since commit 31ade30692dc9680bfc95700d794818fa3f754ac, timekeeping_init()
checks for presence of persistent clock by attempting to read a non-zero
time value. This is an issue on platforms where persistent_clock (instead
is implemented as a free-running counter (instead of an RTC) starting
from zero on each boot and running during suspend. Examples are some ARM
platforms (e.g. PandaBoard).
An attempt to read such a clock during timekeeping_init() may return zero
value and falsely declare persistent clock as missing. Additionally, in
the above case suspend times may be accounted twice (once from
timekeeping_resume() and once from rtc_resume()), resulting in a gradual
drift of system time.
This patch does a run-time correction of the issue by doing the same check
during timekeeping_suspend().
A better long-term solution would have to return error when trying to read
non-existing clock and zero when trying to read an uninitialized clock, but
that would require changing all persistent_clock implementations.
This patch addresses the immediate breakage, for now.
Cc: John Stultz <john.stultz@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Feng Tang <feng.tang@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org>
[jstultz: Tweaked commit message and subject]
Signed-off-by: John Stultz <john.stultz@linaro.org>
Diffstat (limited to 'drivers')
0 files changed, 0 insertions, 0 deletions