Re: [PATCH 2/2] power: reset: at91-reset: add sysfs interface to the power on reason

[Miquel Raynal]

Hi Sebastian,

sebastian.reichel@xxxxxxxxxxxxx wrote on Sat, 10 Jun 2023 01:36:59
+0200:

> Hi,
> 
> On Fri, Jun 09, 2023 at 04:39:12PM +0200, Miquel Raynal wrote:
> > From: Kamel Bouhara <kamel.bouhara@xxxxxxxxxxx>
> > 
> > Introduce a list of generic reset sources and use them to export the
> > power on reason through sysfs. Update the ABI documentation to describe
> > this new interface.
> > 
> > Signed-off-by: Kamel Bouhara <kamel.bouhara@xxxxxxxxxxx>
> > Acked-by: Nicolas Ferre <nicolas.ferre@xxxxxxxxxxxxx>
> > [Miquel Raynal: Follow-up on Kamel's work, 4 years later]
> > Signed-off-by: Miquel Raynal <miquel.raynal@xxxxxxxxxxx>
> > ---
> >  .../testing/sysfs-platform-power-on-reason    | 10 +++++
> >  drivers/power/reset/at91-reset.c              | 42 +++++++++++++------
> >  include/linux/power/power_on_reason.h         | 19 +++++++++
> >  3 files changed, 59 insertions(+), 12 deletions(-)
> >  create mode 100644 Documentation/ABI/testing/sysfs-platform-power-on-reason
> >  create mode 100644 include/linux/power/power_on_reason.h
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-platform-power-on-reason b/Documentation/ABI/testing/sysfs-platform-power-on-reason
> > new file mode 100644
> > index 000000000000..12020d017543
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-platform-power-on-reason
> > @@ -0,0 +1,10 @@
> > +What:		/sys/devices/platform/.../power_on_reason
> > +Date:		October 2019
> > +KernelVersion:	5.4  
> 
> That needs to be updated :)

/o\

> 
> > +Contact:	Kamel Bouhara <kamel.bouhara@xxxxxxxxxxx>
> > +Description:	This file shows system power on reason. Possible sources are:
> > +		General system power-on, RTC wakeup, watchdog timeout, software
> > +		reset, user pressed reset button, CPU clock failure, oscillator
> > +		failure, low power mode exit, unknown.
> > +
> > +		The file is read only.  
> 
> This should list the exact strings generated by the kernel. They are
> ABI. Also it should be mentioned, that the list might be extended in
> the future.

Ah, ok, sure.

> 
> > diff --git a/drivers/power/reset/at91-reset.c b/drivers/power/reset/at91-reset.c  
> 
> [...]
> 
> > diff --git a/include/linux/power/power_on_reason.h b/include/linux/power/power_on_reason.h
> > new file mode 100644
> > index 000000000000..4b92eb0519c4
> > --- /dev/null
> > +++ b/include/linux/power/power_on_reason.h
> > @@ -0,0 +1,19 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * Author: Kamel Bouhra <kamel.bouhara@xxxxxxxxxxx>
> > + */
> > +
> > +#ifndef POWER_ON_REASON_H
> > +#define POWER_ON_REASON_H
> > +
> > +#define POWER_ON_REASON_GENERAL "general"  
> 
> What's the difference between "general" and "unknown"?

This reset value is returned when the reset controller detects rising
power rails. It is basically a "I just plugged the power connector"
situation.

Maybe I can rename it:

#define POWER_ON_REASON_REGULAR "regular power-up"

?

The "unknown" situation is more like a "it does not match what I
expect/know". Might be because support for a new reason was added to
another SoC where these enums would be used but not added to the driver
(yet).

Questioning the low-power situation remark you made below, we could
also imagine that, under certain brownout conditions, where the status
register might somehow be corrupted (assuming if this happens, the
other reasons will not appear), we might want to return that "unknown"
reason which sounds more like a software thing for handling default
case statements.

> > +#define POWER_ON_REASON_RTC "RTC wakeup"
> > +#define POWER_ON_REASON_WATCHDOG "watchdog timeout"
> > +#define POWER_ON_REASON_SOFTWARE "software"  
> 
> "software reset"

Yes.

> 
> > +#define POWER_ON_REASON_USER "user"  
> 
> user is quite confusing. This should be something like
> 
> #define POWER_ON_REASON_RST_BTN "reset button"

Agreed. Maybe even "reset button action" so it fits better the "Starting
after %s" string, like the other reasons.

> 
> > +#define POWER_ON_REASON_CPU_FAIL "CPU clock failure"  
> 
> POWER_ON_REASON_CPU_CLK_FAIL
> 
> > +#define POWER_ON_REASON_XTAL_FAIL "crystal oscillator failure"
> > +#define POWER_ON_REASON_LOW_POWER "low power exit"  
> 
> when is this reported?

I am currently using a Sama5d3 where this reason does not exist, but
given how are defined the other reasons, I would assume that the reset
controller might be able to monitor the power rails, and report this
condition upon a short brownout, like: "there is temporarily not enough
power => CPU reset", but in the mean time, the capacitors allowed the
hardware to retain that information and this does not appear like a
regular power up situation. Just guessing, I did not find yet a proper
explanation.

Anyhow, I will change the string to "low-power condition" which sounds
better IMHO.

> > +#define POWER_ON_REASON_UNKNOWN "unknown"

And here "unknown reason"

> > +
> > +#endif /* POWER_ON_REASON_H */  
> 
> Greetings,
> 
> -- Sebastian

Thanks,
Miquèl