public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
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
> 
> 


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox