linux-rtc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: "Mateusz Jończyk" <mat.jonczyk@o2.pl>
Cc: linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org,
	Alessandro Zummo <a.zummo@towertech.it>
Subject: Re: [PATCH] rtc-mc146818-lib: wait longer for UIP to clear
Date: Sat, 12 Feb 2022 23:42:21 +0100	[thread overview]
Message-ID: <Ygg3zXX+vgBhDb30@piout.net> (raw)
In-Reply-To: <20220212220454.566548-1-mat.jonczyk@o2.pl>

Hello,

On 12/02/2022 23:04:54+0100, Mateusz Jończyk wrote:
> 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.
> 

I'm not going to apply that until we actually have reports that there
are issues because now, we can't know what is the benefit risk balance.

> 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 (always hitting RTC read
> timeout) - which may constantly occupy one CPU. This looks very
> unlikely, though.
> 
> Also fix "then" -> "than" in a comment.
> 
> 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")
> ---
> 
> This comment from Mr Alexandre Belloni got me thinking and is why I am
> submitting 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/ )
> 
> Googling for dmesg messages that indicate problems with reading from RTC
> (such as "unable to read current time" - using quotation marks to force
> exact phrase search) produces no results apart from kernel code and
> patches. Any problems would happen rarely on affected systems, though.
> 
>  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 ae9f131b43c0..29ceec9875f4 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)
>  {
> 
> base-commit: dfd42facf1e4ada021b939b4e19c935dcdd55566
> -- 
> 2.25.1
> 

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

      reply	other threads:[~2022-02-12 22:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-12 22:04 [PATCH] rtc-mc146818-lib: wait longer for UIP to clear Mateusz Jończyk
2022-02-12 22:42 ` Alexandre Belloni [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=Ygg3zXX+vgBhDb30@piout.net \
    --to=alexandre.belloni@bootlin.com \
    --cc=a.zummo@towertech.it \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=mat.jonczyk@o2.pl \
    /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).