[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <875z5id5v0.fsf@nanos.tec.linutronix.de>
Date: Thu, 03 Dec 2020 20:52:51 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Alexandre Belloni <alexandre.belloni@...tlin.com>
Cc: Jason Gunthorpe <jgg@...pe.ca>,
Miroslav Lichvar <mlichvar@...hat.com>,
linux-kernel@...r.kernel.org, John Stultz <john.stultz@...aro.org>,
Prarit Bhargava <prarit@...hat.com>,
Alessandro Zummo <a.zummo@...ertech.it>,
linux-rtc@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] rtc: adapt allowed RTC update error
Alexandre,
On Thu, Dec 03 2020 at 18:29, Alexandre Belloni wrote:
> On 03/12/2020 16:39:21+0100, Thomas Gleixner wrote:
>> On Thu, Dec 03 2020 at 03:10, Alexandre Belloni wrote:
>> > On 03/12/2020 02:14:12+0100, Thomas Gleixner wrote:
>> > Coincidentally, I was going to revert those patches for v5.11.
>>
>> Which will break the rtc_cmos() driver in a different way. We should
>> really fix that proper and just have the 500ms offset for rtc_cmos,
>> aka. MC146818. When other drivers want a different offset, then they
>> still can do so.
>>
>
> My point was to get back to the previous situation where only
> rtc_cmos was supposed to work properly by removing rtc_tv_nsec_ok and
> set_offset_nsec.
If you remove the offset, then rtc_cmos() is off by ~500ms.
> I'm still convinced that set_offset_nsec is not needed to set the time
> accurately and I still want to remove it. Also, this may be a good time
> to move systohc.c to kernel/time/ntp.c as this is definitively some NTP
> specific code being an RTC consumer, very much like alarmtimer.c
No objections from my side.
The main pain point is that the periodic update is seen as ABI by some
folks. The fact that you can disable it in Kconfig does not matter. You
can disable other stuff like posix timers which is ABI as well.
So removing it is not really an option. Keeping it broken or break it
differently is neither...
Thanks,
tglx
Powered by blists - more mailing lists