[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5efcbdad-972d-2159-34ea-97eb6e29c613@o2.pl>
Date: Fri, 10 Dec 2021 20:05:38 +0100
From: Mateusz Jończyk <mat.jonczyk@...pl>
To: Alexandre Belloni <alexandre.belloni@...tlin.com>
Cc: linux-kernel@...r.kernel.org, linux-rtc@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>,
Alessandro Zummo <a.zummo@...ertech.it>
Subject: Re: [PATCH RESEND v3 2/7] rtc-mc146818-lib: fix RTC presence check
W dniu 10.12.2021 o 16:26, Alexandre Belloni pisze:
> Hi,
>
> On 25/11/2021 23:12:42+0100, Mateusz Jończyk wrote:
>> W dniu 24.11.2021 o 23:31, Alexandre Belloni pisze:
>>> Hello,
>>>
>>> By moving this patch later on in the series, you'd avoid the subsequent
>>> refactor. I think this would be better for bisection later on.
>> Hi,
>>
>> There are three issues I'm trying to fix in this series:
>>
>> 1. (less important) Insufficient locking in cmos_set_alarm()
>> 2. misdetection of the RTC CMOS as broken on some motherboards,
>> 3. reading / writing of the RTC alarm time during RTC update-in-progress.
>>
>> Do you mean I should drop the patch
>> nr 2. ("rtc-mc146818-lib: fix RTC presence check")
>> and instead straight away introduce mc146818_avoid_UIP() with the new approach (as in patch 3 in the series),
>> then modify mc146818_get_time() to use it (as in patch 4 - fixing issue nr 2),
>> then modify cmos_read_alarm / cmos_set_alarm to use mc146818_avoid_UIP() (patches 5-6, fixing issue no. 3)?
>>
>> I was afraid this risks some confusion what is being fixed when.
> I realize I never replied to this. This is fine, I'm planning to apply
> the whole series once the few comments are fixed.
Great!
I've got other things mostly sorted out and tested, so I'll send a v4 shortly after some last-minute checks.
> We'll probably get some breakage later on because many RTCs using this
> driver are not adhering to the spec.
>
Thanks,
Mateusz
Powered by blists - more mailing lists