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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <9e12863cf7ec0284b632226c31403d740dd32350.camel@siemens.com>
Date: Tue, 7 Jan 2025 10:06:11 +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!

On Fri, 2024-03-01 at 12:10 +0100, Alexander Sverdlin wrote:
> 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.

The patch is not addressing possible run-time power loss, but rather
an issue with PoR function, documented by the vendor. Do you still have
some doubts regarding the explanation above?

For the PoR issue placing the workaround into probe function seems to
be fine, IMO. Could you please re-consider the patch?

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com