linux-kernel - Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st

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: <CAD=FV=VJKHK2Eu75UJPf+3i7Gaxa09g+Hwfy7nwWYrgMvocarg@mail.gmail.com>
Date:	Sun, 6 Dec 2015 18:52:22 -0800
From:	Doug Anderson <dianders@...omium.org>
To:	Chris Zhong <zyw@...k-chips.com>
Cc:	Julius Werner <jwerner@...omium.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Alessandro Zummo <a.zummo@...ertech.it>,
	Sonny Rao <sonnyrao@...omium.org>,
	Heiko Stuebner <heiko@...ech.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	rtc-linux@...glegroups.com
Subject: Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st

Hi,

On Sun, Dec 6, 2015 at 6:50 PM, Doug Anderson <dianders@...omium.org> wrote:
> Chris,
>
> On Sun, Dec 6, 2015 at 5:33 PM, Chris Zhong <zyw@...k-chips.com> wrote:
>> Hi Doug
>>
>> RK808 has a shadowed register for saving a "frozen" RTC time.
>> When we setting "GET_TIME" to 1, the time will save in this shadowed
>> register. So if we do not set the "GET_TIME", we always get the last time.
>>
>> read the old time before "get_time", and then read the time again for new
>> time. If the old time earlier than 12.1 && new time later than 12.1, we
>> should
>> +1 day for the correct rtc time.
>>
>> On the other hand, we should set the "GET_TIME" after rk808_rtc_set_time,
>> for restore the time before suspend/shut_down.
>
> Ah, good idea using the shadow registers.  The whole point of the
> shadow registers is to enable atomic read of time, right?  So if the
> clock ticks as you are reading 23:59:59 you don't end up reading
> 23:59:00 or 24:59:59 (you'll get either 23:59:59 or 24:00:00).  So
> right, time read will now be:
>
> 1. Read GET_TIME.  Confirm it's 1.
> 2. Read the time.
> 3. Set GET_TIME to 0.
> 4. Set GET_TIME to 1.
> 5. Read the time.
>
> If time from #2 < 11/31 and time from #5 >= 11/31 then we do the
> adjust.  If GET_TIME wasn't 1 in step #1 then we won't do any
> adjusting unless the time is actually 11/31.
>
> Between steps #4 and #5 we'll need to add a small delay since old code
> used to use the setting to 0 as a delay (as commented).
>
> We should presumably always leave GET_TIME as 1 unless we're actively
> reading the time for the most reliability.  Also, if we've already
> read the time this bootup, we can certainly optimize the above by
> skipping #1 and #2.

Oh, but also we still need to know whether to adjust the alarm.  I
think you said that all existing rk808 chips have this bug and that
you'll set a bit (to be determined later) if/when this bug is fixed.
So we still need to assume that all rk808 chips have this bug...

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/