[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87pmpxlcrd.ffs@tglx>
Date: Wed, 15 Dec 2021 23:33:10 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: John Stultz <john.stultz@...aro.org>,
Alexandre Belloni <alexandre.belloni@...tlin.com>
Cc: Joel Daniels <jdaniels@...t.com>, Stephen Boyd <sboyd@...nel.org>,
linux-kernel@...r.kernel.org,
Alessandro Zummo <a.zummo@...ertech.it>,
linux-rtc@...r.kernel.org, x86@...nel.org
Subject: Re: Time keeping while suspended in the presence of persistent
clock drift
On Wed, Dec 15 2021 at 14:02, John Stultz wrote:
> On Wed, Dec 15, 2021 at 1:32 PM Alexandre Belloni
>> I'd rather lean towards the timekeeping code doing that. The RTC
>
> Heh, touche'! :)
>
>> subsystem doesn't know which RTC has to be used.
>
> Though the RTC layer *is* the one that tracks which RTC is used, via
> the logic in drivers/rtc/class.c, and the timekeeping core already has
> adjtimex for timekeeping corrections, so if we're correcting
> underlying RTCs it seems such tuning would best be done in the RTC
> layer.
>
> Though how the persistent_clock interface ties into such corrections
> would be a separate thing.
Might be the final trigger to get rid of that leftover from the last
millenium?
Thanks,
tglx
Powered by blists - more mailing lists