From: "Mateusz Jończyk" <mat.jonczyk@o2.pl>
To: Mario Limonciello <mario.limonciello@amd.com>,
Alessandro Zummo <a.zummo@towertech.it>,
Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: "open list:REAL TIME CLOCK (RTC) SUBSYSTEM"
<linux-rtc@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
linux-pm@vger.kernel.org, tobrohl@gmail.com, aalsing@gmail.com,
Dhaval.Giani@amd.com, xmb8dsv4@gmail.com, x86@kernel.org
Subject: Re: [PATCH 3/4] rtc: Add support for configuring the UIP timeout for RTC reads
Date: Sat, 18 Nov 2023 20:06:59 +0100 [thread overview]
Message-ID: <9a34ad89-6263-4cda-b938-348bdf62e155@o2.pl> (raw)
In-Reply-To: <20231117063220.65093-4-mario.limonciello@amd.com>
Hello,
W dniu 17.11.2023 o 07:32, Mario Limonciello pisze:
> The UIP timeout is hardcoded to 10ms for all RTC reads, but in some
> contexts this might not be enough time. Add a timeout parameter to
> mc146818_get_time() and mc146818_get_time_callback().
> Make all callers use 10ms to ensure no functional changes.
>
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Fixes: ec5895c0f2d8 ("rtc: mc146818-lib: extract mc146818_avoid_UIP")
If you would like to Cc: stable this patch,
commit d2a632a8a117 ("rtc: mc146818-lib: reduce RTC_UIP polling period")
is a prerequisite.
> ---
> arch/alpha/kernel/rtc.c | 2 +-
> arch/x86/kernel/hpet.c | 2 +-
> arch/x86/kernel/rtc.c | 2 +-
> drivers/base/power/trace.c | 2 +-
> drivers/rtc/rtc-cmos.c | 6 +++---
> drivers/rtc/rtc-mc146818-lib.c | 31 +++++++++++++++++++++++--------
> include/linux/mc146818rtc.h | 3 ++-
> 7 files changed, 32 insertions(+), 16 deletions(-)
>
[snip]
> --- a/drivers/rtc/rtc-mc146818-lib.c
> +++ b/drivers/rtc/rtc-mc146818-lib.c
> @@ -8,26 +8,29 @@
> #include <linux/acpi.h>
> #endif
>
> +#define UIP_RECHECK_DELAY 100 /* usec */
> +
> /*
> * Execute a function while the UIP (Update-in-progress) bit of the RTC is
> - * unset.
> + * unset. The timeout is configurable by the caller in ms.
> *
> * Warning: callback may be executed more then once.
> */
> bool mc146818_avoid_UIP(void (*callback)(unsigned char seconds, void *param),
> + int timeout,
> void *param)
> {
> int i;
> unsigned long flags;
> unsigned char seconds;
>
> - for (i = 0; i < 100; i++) {
> + for (i = 0; i < USEC_PER_MSEC / UIP_RECHECK_DELAY * timeout; i++) {
> spin_lock_irqsave(&rtc_lock, flags);
>
> /*
> * Check whether there is an update in progress during which the
> * readout is unspecified. The maximum update time is ~2ms. Poll
> - * every 100 usec for completion.
> + * for completion.
> *
> * Store the second value before checking UIP so a long lasting
> * NMI which happens to hit after the UIP check cannot make
> @@ -37,7 +40,7 @@ bool mc146818_avoid_UIP(void (*callback)(unsigned char seconds, void *param),
>
> if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP) {
> spin_unlock_irqrestore(&rtc_lock, flags);
> - udelay(100);
> + udelay(UIP_RECHECK_DELAY);
> continue;
> }
>
> @@ -56,7 +59,7 @@ bool mc146818_avoid_UIP(void (*callback)(unsigned char seconds, void *param),
> */
> if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP) {
> spin_unlock_irqrestore(&rtc_lock, flags);
> - udelay(100);
> + udelay(UIP_RECHECK_DELAY);
> continue;
> }
>
I think that when reading the RTC is not finished in 100ms or so
(irrespective of the timeout parameter), the code should log
a warning / an error message.
Greetings,
Mateusz
next prev parent reply other threads:[~2023-11-18 19:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-17 6:32 [PATCH 0/4] Extend time to wait for UIP for some callers Mario Limonciello
2023-11-17 6:32 ` [PATCH 1/4] rtc: mc146818-lib: Adjust failure return code for mc146818_get_time() Mario Limonciello
2023-11-17 6:32 ` [PATCH 2/4] rtc: Adjust failure return code for cmos_set_alarm() Mario Limonciello
2023-11-18 18:55 ` Mateusz Jończyk
2023-11-17 6:32 ` [PATCH 3/4] rtc: Add support for configuring the UIP timeout for RTC reads Mario Limonciello
2023-11-18 19:06 ` Mateusz Jończyk [this message]
2023-11-17 6:32 ` [PATCH 4/4] rtc: Extend timeout for waiting for UIP to clear to 1s Mario Limonciello
2023-11-18 19:25 ` Mateusz Jończyk
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=9a34ad89-6263-4cda-b938-348bdf62e155@o2.pl \
--to=mat.jonczyk@o2.pl \
--cc=Dhaval.Giani@amd.com \
--cc=a.zummo@towertech.it \
--cc=aalsing@gmail.com \
--cc=alexandre.belloni@bootlin.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=tobrohl@gmail.com \
--cc=x86@kernel.org \
--cc=xmb8dsv4@gmail.com \
/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