linux-kernel - Re: [PATCH] rtc: pcf85063: do a SW reset after rtc power fail

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 for Android: free password hash cracker in your pocket

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

Message-ID: <f882d7964d2d905288bcb7d01421b5eb5bd1b6f2.camel@siemens.com>
Date: Fri, 1 Mar 2024 11:10:12 +0000
From: "Sverdlin, Alexander" <alexander.sverdlin@...mens.com>
To: "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>
CC: "Stockmann, Lukas" <lukas.stockmann@...mens.com>,
	"linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] rtc: pcf85063: do a SW reset after rtc power fail

Hello Alexandre!

Thank you for your review!

On Thu, 2024-02-29 at 23:08 +0100, Alexandre Belloni wrote:
> > "There is a low probability that some devices will have corruption of the
> > registers after the automatic power-on reset if the device is powered up
> > with a residual VDD level. It is required that the VDD starts at zero volts

...

> Doing this in probe is putting a band-aid on a wooden leg as you are not
> guaranteed you will have a probe to catch this case. This should be
> rather done in pcf85063_rtc_set_time but it comes with its own set of

As I read the datasheet (quoted above) the device has "peculiarities" in
Power-On-Reset implementation, namely it's not always detected. In our
applications (and probably most other designs) it's the startup of Linux
with driver probe, which immediately follows the Power-On event
(which had some residue voltage because of large capacitors, whatsoever).

It is an issue we really observed and solved in 100% cases for our design.
I just thought it might be useful for others because it's also documented
by NXP. Maybe not as separate errata document and it's a bit hidden in
datasheet but I'd ultimately consider it a POR errata.

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com