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: <20230615162905.71e1443d@xps-13>
Date:   Thu, 15 Jun 2023 16:29:05 +0200
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Sebastian Reichel <sebastian.reichel@...labora.com>
Cc:     Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Claudiu Beznea <claudiu.beznea@...rochip.com>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-pm@...r.kernel.org,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Kamel Bouhara <kamel.bouhara@...tlin.com>
Subject: Re: [PATCH 2/2] power: reset: at91-reset: add sysfs interface to
 the power on reason

Hi Sebastian,

sebastian.reichel@...labora.com 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@...tlin.com>
> > 
> > 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@...tlin.com>
> > Acked-by: Nicolas Ferre <nicolas.ferre@...rochip.com>
> > [Miquel Raynal: Follow-up on Kamel's work, 4 years later]
> > Signed-off-by: Miquel Raynal <miquel.raynal@...tlin.com>
> > ---
> >  .../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@...tlin.com>
> > +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@...tlin.com>
> > + */
> > +
> > +#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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ