From: Mario Limonciello <mario.limonciello@amd.com>
To: "Mateusz Jończyk" <mat.jonczyk@o2.pl>,
"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,
dhaval.giani@gmail.com, Dave Hansen <dave.hansen@linux.intel.com>,
Borislav Petkov <bp@alien8.de>, "H . Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH v3 3/4] rtc: Add support for configuring the UIP timeout for RTC reads
Date: Mon, 27 Nov 2023 14:37:45 -0600 [thread overview]
Message-ID: <4332dbf1-76be-434a-a65a-d4686cb4d2fd@amd.com> (raw)
In-Reply-To: <c179a0cb-1b98-4a4f-a3c6-cad7b980a337@o2.pl>
On 11/27/2023 14:31, Mateusz Jończyk wrote:
> W dniu 27.11.2023 o 20:25, 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().
>>
>> If UIP timeout is configured by caller to be >=100 ms and a call
>> takes this long, log a warning.
>>
>> Make all callers use 10ms to ensure no functional changes.
>>
>> Cc: stable@vger.kernel.org # 6.1.y
>> Fixes: ec5895c0f2d8 ("rtc: mc146818-lib: extract mc146818_avoid_UIP")
>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>> ---
>> v2->v3:
>> * Logic adjustments
>> * Clarify warning message
>> v1->v2:
>> * Add a warning if 100ms or more
>> * Add stable and fixes tags
> [snip]
>> diff --git a/drivers/rtc/rtc-mc146818-lib.c b/drivers/rtc/rtc-mc146818-lib.c
>> index 43a28e82674e..ab077dde397b 100644
>> --- a/drivers/rtc/rtc-mc146818-lib.c
>> +++ b/drivers/rtc/rtc-mc146818-lib.c
>> @@ -8,26 +8,31 @@
>> #include <linux/acpi.h>
>> #endif
>>
>> +#define UIP_RECHECK_DELAY 100 /* usec */
>> +#define UIP_RECHECK_DELAY_MS (USEC_PER_MSEC / UIP_RECHECK_DELAY)
>> +#define UIP_RECHECK_TIMEOUT_MS(x) (x / UIP_RECHECK_DELAY_MS)
>> +
>> /*
>> * 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 < UIP_RECHECK_TIMEOUT_MS(timeout); i++) {
>
> Sorry, this will not work. UIP_RECHECK_DELAY_MS is 10, so
> UIP_RECHECK_TIMEOUT_MS(timeout) will be 1 for timeout=10. Should be
>
> for (i = 0; UIP_RECHECK_TIMEOUT_MS(i) < timeout; i++) {
>
> With this, for i == 99, UIP_RECHECK_TIMEOUT_MS(i) = 9
> for i == 100, UIP_RECHECK_TIMEOUT_MS(i) = 10 and the loop correctly terminates.
>
> The macro should probably be renamed UIP_RECHECK_LOOPS_MS as it converts
> loop count to ms.
Got it; thanks for that.
>
>> 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 +42,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 +61,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;
>> }
>>
>> @@ -72,6 +77,10 @@ bool mc146818_avoid_UIP(void (*callback)(unsigned char seconds, void *param),
>> }
>> spin_unlock_irqrestore(&rtc_lock, flags);
>>
>> + if (i >= UIP_RECHECK_TIMEOUT_MS(100))
>
> Same, should be:
>
> if (UIP_RECHECK_TIMEOUT_MS(i) >= 100)
>
>> + pr_warn("Reading current time from RTC took around %d ms\n",
>> + UIP_RECHECK_TIMEOUT_MS(i));
>> +
>> return true;
>> }
>> return false;
>
> [snip]
>
> Greetings,
>
> Mateusz
>
>
next prev parent reply other threads:[~2023-11-27 20:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-27 19:25 [PATCH v3 0/4] Extend time to wait for UIP for some callers Mario Limonciello
2023-11-27 19:25 ` [PATCH v3 1/4] rtc: mc146818-lib: Adjust failure return code for mc146818_get_time() Mario Limonciello
2023-11-27 19:25 ` [PATCH v3 2/4] rtc: Adjust failure return code for cmos_set_alarm() Mario Limonciello
2023-11-27 19:25 ` [PATCH v3 3/4] rtc: Add support for configuring the UIP timeout for RTC reads Mario Limonciello
2023-11-27 20:31 ` Mateusz Jończyk
2023-11-27 20:37 ` Mario Limonciello [this message]
2023-11-28 0:19 ` kernel test robot
2023-11-28 3:01 ` kernel test robot
2023-11-27 19:25 ` [PATCH v3 4/4] rtc: Extend timeout for waiting for UIP to clear to 1s Mario Limonciello
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=4332dbf1-76be-434a-a65a-d4686cb4d2fd@amd.com \
--to=mario.limonciello@amd.com \
--cc=Dhaval.Giani@amd.com \
--cc=a.zummo@towertech.it \
--cc=aalsing@gmail.com \
--cc=alexandre.belloni@bootlin.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dhaval.giani@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=mat.jonczyk@o2.pl \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.