linux-kernel - Re: [PATCH 4/6] rtc: rv8803: Always apply the I²C workaround

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:	Thu, 21 Jul 2016 14:34:54 +0200
From:	Benoît Thébaudeau <benoit@...stem.com>
To:	Alexandre Belloni <alexandre.belloni@...e-electrons.com>
Cc:	rtc-linux@...glegroups.com, linux-kernel@...r.kernel.org,
	Alessandro Zummo <a.zummo@...ertech.it>
Subject: Re: [PATCH 4/6] rtc: rv8803: Always apply the I²C workaround

On 21/07/2016 at 13:10, Alexandre Belloni wrote:
> On 21/07/2016 at 12:41:30 +0200, Benoît Thébaudeau wrote :
>> The I²C NACK issue of the RV-8803 may occur after any I²C START
>> condition, depending on the timings. Consequently, the workaround must
>> be applied for all the I²C transfers.
>>
>> This commit abstracts the I²C transfer code into register access
>> functions. This avoids duplicating the I²C workaround everywhere. This
>> also avoids the duplication of the code handling the return value of
>> i2c_smbus_read_i2c_block_data(). Error messages are issued in case of
>> definitive register access failures (if the workaround fails). This
>> change also makes the I²C transfer return value checks consistent.
>>
> 
> Well, my initial idea was that the workaround is actually needed only
> for operations that are not restartable from userspace.
> 
> Did you it that bug? On which RTC?

No, I've not seen that bug. However, the errata sheet says that this issue may
occur if two consecutive I²C START conditions are slightly more than 950 ms
apart. It does not even say that this is restricted to I²C transfers addressing
this RTC. Moreover, if the time is read or set from userspace, this might occur
at any time relatively to an RTC interrupt or to a previous time read/set
operation, so possibly 950 ms afterwards.

All in all, it's safer and easier to always apply this workaround, all the more
it is applied at almost no cost when there is no issue.

Best regards,
Benoît