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]
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
>>
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ