From: Lukas Stockmann <lukas.stockmann@siemens.com>

From PCF85063A datasheet, section "Software reset":

"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
at power up or upon power cycling to ensure that there is no corruption of
the registers. If this is not possible, a reset must be initiated after
power-up (i.e. when power is stable) with the software reset command"

Trigger SW reset if a power loss is detected.

Link: https://www.nxp.com/docs/en/data-sheet/PCF85063A.pdf
Signed-off-by: Lukas Stockmann <lukas.stockmann@siemens.com>
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
---
 drivers/rtc/rtc-pcf85063.c | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-pcf85063.c b/drivers/rtc/rtc-pcf85063.c
index fdbc07f14036..edfd75d18e19 100644
--- a/drivers/rtc/rtc-pcf85063.c
+++ b/drivers/rtc/rtc-pcf85063.c
@@ -35,6 +35,7 @@
 #define PCF85063_REG_CTRL1_CAP_SEL	BIT(0)
 #define PCF85063_REG_CTRL1_STOP		BIT(5)
 #define PCF85063_REG_CTRL1_EXT_TEST	BIT(7)
+#define PCF85063_REG_CTRL1_SWR		0x58
 
 #define PCF85063_REG_CTRL2		0x01
 #define PCF85063_CTRL2_AF		BIT(6)
@@ -580,7 +581,7 @@ static int pcf85063_probe(struct i2c_client *client)
 
 	i2c_set_clientdata(client, pcf85063);
 
-	err = regmap_read(pcf85063->regmap, PCF85063_REG_CTRL1, &tmp);
+	err = regmap_read(pcf85063->regmap, PCF85063_REG_SC, &tmp);
 	if (err) {
 		dev_err(&client->dev, "RTC chip is not present\n");
 		return err;
@@ -590,6 +591,22 @@ static int pcf85063_probe(struct i2c_client *client)
 	if (IS_ERR(pcf85063->rtc))
 		return PTR_ERR(pcf85063->rtc);
 
+	/*
+	 * If a Power loss is detected, SW reset the device.
+	 * From PCF85063A datasheet:
+	 * There is a low probability that some devices will have corruption
+	 * of the registers after the automatic power-on reset...
+	 */
+	if (tmp & PCF85063_REG_SC_OS) {
+		dev_warn(&client->dev,
+			 "Power loss detected, send a SW reset to the device\n");
+		err = regmap_write(pcf85063->regmap, PCF85063_REG_CTRL1,
+				PCF85063_REG_CTRL1_SWR);
+		if (err < 0)
+			dev_err(&client->dev,
+				"SW reset failed, trying to continue\n");
+	}
+
 	err = pcf85063_load_capacitance(pcf85063, client->dev.of_node,
 					config->force_cap_7000 ? 7000 : 0);
 	if (err < 0)
-- 
2.43.2

On 27/02/2024 14:14:32+0100, A. Sverdlin wrote:
> From: Lukas Stockmann <lukas.stockmann@siemens.com>
> 
> From PCF85063A datasheet, section "Software reset":
> 
> "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
> at power up or upon power cycling to ensure that there is no corruption of
> the registers. If this is not possible, a reset must be initiated after
> power-up (i.e. when power is stable) with the software reset command"
> 
> Trigger SW reset if a power loss is detected.
> 
> Link: https://www.nxp.com/docs/en/data-sheet/PCF85063A.pdf
> Signed-off-by: Lukas Stockmann <lukas.stockmann@siemens.com>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
> ---
>  drivers/rtc/rtc-pcf85063.c | 19 ++++++++++++++++++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/rtc/rtc-pcf85063.c b/drivers/rtc/rtc-pcf85063.c
> index fdbc07f14036..edfd75d18e19 100644
> --- a/drivers/rtc/rtc-pcf85063.c
> +++ b/drivers/rtc/rtc-pcf85063.c
> @@ -35,6 +35,7 @@
>  #define PCF85063_REG_CTRL1_CAP_SEL	BIT(0)
>  #define PCF85063_REG_CTRL1_STOP		BIT(5)
>  #define PCF85063_REG_CTRL1_EXT_TEST	BIT(7)
> +#define PCF85063_REG_CTRL1_SWR		0x58
>  
>  #define PCF85063_REG_CTRL2		0x01
>  #define PCF85063_CTRL2_AF		BIT(6)
> @@ -580,7 +581,7 @@ static int pcf85063_probe(struct i2c_client *client)
>  
>  	i2c_set_clientdata(client, pcf85063);
>  
> -	err = regmap_read(pcf85063->regmap, PCF85063_REG_CTRL1, &tmp);
> +	err = regmap_read(pcf85063->regmap, PCF85063_REG_SC, &tmp);
>  	if (err) {
>  		dev_err(&client->dev, "RTC chip is not present\n");
>  		return err;
> @@ -590,6 +591,22 @@ static int pcf85063_probe(struct i2c_client *client)
>  	if (IS_ERR(pcf85063->rtc))
>  		return PTR_ERR(pcf85063->rtc);
>  
> +	/*
> +	 * If a Power loss is detected, SW reset the device.
> +	 * From PCF85063A datasheet:
> +	 * There is a low probability that some devices will have corruption
> +	 * of the registers after the automatic power-on reset...
> +	 */
> +	if (tmp & PCF85063_REG_SC_OS) {
> +		dev_warn(&client->dev,
> +			 "Power loss detected, send a SW reset to the device\n");
> +		err = regmap_write(pcf85063->regmap, PCF85063_REG_CTRL1,
> +				PCF85063_REG_CTRL1_SWR);
> +		if (err < 0)
> +			dev_err(&client->dev,
> +				"SW reset failed, trying to continue\n");
> +	}

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
issues because this probably requires to reconfigure most of the chip
which is conveniently done in probe. And then it will introduce varance
in the time taken to set_time which is generally bad if you care about
sub second precision.


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

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