linux-kernel - Re: [PATCH] rtc: Fix set RTC time delay 500ms on some Zhaoxin SOCs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a4b6b0b4-9aa5-9a75-e523-0fd7656b82cf@zhaoxin.com>
Date:   Mon, 16 Aug 2021 18:03:13 +0800
From:   Tony W Wang-oc <TonyWWang-oc@...oxin.com>
To:     Alexandre Belloni <alexandre.belloni@...tlin.com>
CC:     <a.zummo@...ertech.it>, <linux-rtc@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <TimGuo-oc@...oxin.com>,
        <CooperYan@...oxin.com>, <QiyuanWang@...oxin.com>,
        <HerryYang@...oxin.com>, <CobeChen@...oxin.com>,
        <YanchenSun@...oxin.com>
Subject: Re: [PATCH] rtc: Fix set RTC time delay 500ms on some Zhaoxin SOCs


On 16/08/2021 16:24, Alexandre Belloni wrote:
> Hello,
> 
> On 16/08/2021 21:47:18+0800, Tony W Wang-oc wrote:
>> When the RTC divider is changed from reset to an operating time base,
>> the first update cycle should be 500ms later. But on some Zhaoxin SOCs,
>> this first update cycle is one second later.
>>
>> So set RTC time on these Zhaoxin SOCs will causing 500ms delay.
>>
> 
> Can you explain what is the relationship between writing the divider and
> the 500ms delay?
>> Isn't the issue that you are using systohc and set_offset_nsec is set to
> NSEC_PER_SEC / 2 ?
> 
No.
When using #hwclock -s to set RTC time and set_offset_nsec is
NSEC_PER_SEC / 2, the function mc146818_set_time() requires the first
update cycle after RTC divider be changed from reset to an operating
mode is 500ms as the MC146818A spec specified. But on some Zhaoxin SOCs,
the first update cycle of RTC is one second later after RTC divider be
changed from reset to an operating mode. So the first update cycle after
RTC divider be changed from reset to an operation mode on These SOCs
will causing 500ms delay with current mc146818_set_time() implementation.

Sincerely
TonyWWang-oc

>> Skip setup RTC divider on these SOCs in mc146818_set_time to fix it.
>>
>> Signed-off-by: Tony W Wang-oc <TonyWWang-oc@...oxin.com>
>> ---
>>  drivers/rtc/rtc-mc146818-lib.c | 18 ++++++++++++++++++
>>  1 file changed, 18 insertions(+)
>>
>> diff --git a/drivers/rtc/rtc-mc146818-lib.c b/drivers/rtc/rtc-mc146818-lib.c
>> index dcfaf09..322f94b 100644
>> --- a/drivers/rtc/rtc-mc146818-lib.c
>> +++ b/drivers/rtc/rtc-mc146818-lib.c
>> @@ -190,8 +190,18 @@ int mc146818_set_time(struct rtc_time *time)
>>  	spin_lock_irqsave(&rtc_lock, flags);
>>  	save_control = CMOS_READ(RTC_CONTROL);
>>  	CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL);
>> +
>> +#ifdef CONFIG_X86
>> +	if (!((boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR ||
>> +		boot_cpu_data.x86_vendor == X86_VENDOR_ZHAOXIN) &&
>> +		(boot_cpu_data.x86 <= 7 && boot_cpu_data.x86_model <= 59))) {
>> +		save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
>> +		CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
>> +	}
>> +#else
>>  	save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
>>  	CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
>> +#endif
>>  
>>  #ifdef CONFIG_MACH_DECSTATION
>>  	CMOS_WRITE(real_yrs, RTC_DEC_YEAR);
>> @@ -209,7 +219,15 @@ int mc146818_set_time(struct rtc_time *time)
>>  #endif
>>  
>>  	CMOS_WRITE(save_control, RTC_CONTROL);
>> +
>> +#ifdef CONFIG_X86
>> +	if (!((boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR ||
>> +		boot_cpu_data.x86_vendor == X86_VENDOR_ZHAOXIN) &&
>> +		(boot_cpu_data.x86 <= 7 && boot_cpu_data.x86_model <= 59)))
>> +		CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
>> +#else
>>  	CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
>> +#endif
>>  
>>  	spin_unlock_irqrestore(&rtc_lock, flags);
>>  
>> -- 
>> 2.7.4
>>
>