linux-rtc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Mateusz Jończyk" <mat.jonczyk@o2.pl>
To: linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: "Mateusz Jończyk" <mat.jonczyk@o2.pl>,
	"Alessandro Zummo" <a.zummo@towertech.it>,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>
Subject: [PATCH] RFC: rtc-mc146818-lib: wait longer for UIP to clear
Date: Fri,  7 Jan 2022 16:34:54 +0100	[thread overview]
Message-ID: <20220107153454.391708-1-mat.jonczyk@o2.pl> (raw)
In-Reply-To: <cccbd4cf-f302-b64d-bf32-abdefbc7c6d0@o2.pl>

Before reading date / time from the CMOS RTC, we wait for the
UIP (Update in progress) bit to clear --- so that the values are correct
and consistent. To avoid a hang, there is a time limit after
which we give up waiting.

Increase the time limit from 10 to 20ms in case there are RTCs out
there that are much slower than expected.

This is to be applied on top of rtc-next.

Note: This may cause problems with hpet_rtc_interrupt() if the CMOS RTC
breaks down while the system is running and RTC update interrupt / RTC
alarm interrupt happens to be enabled (which should be rare).
hpet_rtc_interrupt() is executed usually 64 times per second and after
this patch it may take up to 20ms to complete - which may constantly
occupy one CPU. This looks very unlikely, though.

So, I don't know whether implementing this change is worth it and even if
20ms is enough. So I'm asking for opinions.

This comment from Mr Alexandre Belloni got me thinking and is why I
consider this patch:
> We'll probably get some breakage later on because many RTCs using this
> driver are not adhering to the spec.
(See: https://lore.kernel.org/linux-rtc/277177e7-46a0-522c-297c-ad3ee0c15793@o2.pl/T/ )

Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Fixes: ec5895c0f2d8 ("rtc: mc146818-lib: extract mc146818_avoid_UIP")
---
 drivers/rtc/rtc-mc146818-lib.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/rtc-mc146818-lib.c b/drivers/rtc/rtc-mc146818-lib.c
index f62e658cbe23..55e7d2a7578a 100644
--- a/drivers/rtc/rtc-mc146818-lib.c
+++ b/drivers/rtc/rtc-mc146818-lib.c
@@ -21,7 +21,7 @@ bool mc146818_avoid_UIP(void (*callback)(unsigned char seconds, void *param),
 	unsigned long flags;
 	unsigned char seconds;
 
-	for (i = 0; i < 10; i++) {
+	for (i = 0; i < 20; i++) {
 		spin_lock_irqsave(&rtc_lock, flags);
 
 		/*
@@ -79,8 +79,8 @@ bool mc146818_avoid_UIP(void (*callback)(unsigned char seconds, void *param),
 EXPORT_SYMBOL_GPL(mc146818_avoid_UIP);
 
 /*
- * If the UIP (Update-in-progress) bit of the RTC is set for more then
- * 10ms, the RTC is apparently broken or not present.
+ * If the UIP (Update-in-progress) bit of the RTC is set for more than
+ * 20ms, the RTC is apparently broken or not present.
  */
 bool mc146818_does_rtc_work(void)
 {
-- 
2.25.1


      reply	other threads:[~2022-01-07 15:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-07 12:49 [PATCH v5 0/9] rtc-cmos,rtc-mc146818-lib: fixes Mateusz Jończyk
2022-01-07 12:49 ` [PATCH v5 1/9] rtc-cmos: take rtc_lock while reading from CMOS Mateusz Jończyk
2022-01-07 12:49 ` [PATCH v5 2/9] rtc: change return values of mc146818_get_time() Mateusz Jończyk
2022-01-07 12:49 ` [PATCH v5 3/9] Check return value from mc146818_get_time() Mateusz Jończyk
2022-01-07 12:49 ` [PATCH v5 4/9] rtc-mc146818-lib: fix RTC presence check Mateusz Jończyk
2022-01-07 12:49 ` [PATCH v5 5/9] rtc-mc146818-lib: extract mc146818_avoid_UIP Mateusz Jończyk
2022-01-07 12:49 ` [PATCH v5 6/9] rtc-mc146818-lib: refactor mc146818_get_time Mateusz Jończyk
2022-01-07 12:49 ` [PATCH v5 7/9] rtc-mc146818-lib: refactor mc146818_does_rtc_work Mateusz Jończyk
2022-01-07 12:49 ` [PATCH v5 8/9] rtc-cmos: avoid UIP when reading alarm time Mateusz Jończyk
2022-01-07 12:51   ` [DEBUG PATCH v5] rtc-cmos: cmos_read_alarm bug demonstration Mateusz Jończyk
2022-03-29 20:02   ` [PATCH v5 8/9] rtc-cmos: avoid UIP when reading alarm time Mateusz Jończyk
2022-01-07 12:49 ` [PATCH v5 9/9] rtc-cmos: avoid UIP when writing " Mateusz Jończyk
2022-01-07 13:03 ` [PATCH v5 0/9] rtc-cmos,rtc-mc146818-lib: fixes Alexandre Belloni
2022-01-07 13:14   ` Mateusz Jończyk
2022-01-07 15:34     ` Mateusz Jończyk [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220107153454.391708-1-mat.jonczyk@o2.pl \
    --to=mat.jonczyk@o2.pl \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@bootlin.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).