From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <5196794C.2030005@linaro.org> Date: Fri, 17 May 2013 11:39:08 -0700 From: John Stultz MIME-Version: 1.0 To: Zoran Markovic CC: linux-kernel@vger.kernel.org, Thomas Gleixner , Feng Tang , stable@vger.kernel.org Subject: Re: [RFC PATCH] timekeeping: Correct run-time detection of real-time clock. References: <1368815045-21209-1-git-send-email-zoran.markovic@linaro.org> In-Reply-To: <1368815045-21209-1-git-send-email-zoran.markovic@linaro.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: On 05/17/2013 11:24 AM, Zoran Markovic wrote: > Since commit <31ade30692dc9680bfc95700d794818fa3f754ac>, timekeeping_init() > checks for presence of persistent clock by attempting to read a non-zero > time value from real-time clock. This is an issue on platforms where > persistent_clock (instead of a RTC) is implemented as a free-running counter > 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 > Cc: Thomas Gleixner > Cc: Feng Tang > Cc: stable@vger.kernel.org > Signed-off-by: Zoran Markovic Thanks for finding and sending this out! I'll queue this for 3.10. thanks again -john