linux-kernel - Re: [RFC PATCH v1 0/7] Introduction of PSCR Framework and Related Components

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] [thread-next>] [day] [month] [year] [list]

Date: Sat, 20 Jan 2024 00:19:09 +0100
From: Sebastian Reichel <sebastian.reichel@...labora.com>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: Rob Herring <robh+dt@...nel.org>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, 
	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>, kernel@...gutronix.de, linux-kernel@...r.kernel.org, 
	Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>, 
	"Rafael J. Wysocki" <rafael@...nel.org>, Daniel Lezcano <daniel.lezcano@...aro.org>, 
	Zhang Rui <rui.zhang@...el.com>, Lukasz Luba <lukasz.luba@....com>, linux-pm@...r.kernel.org, 
	devicetree@...r.kernel.org, Søren Andersen <san@...v.dk>
Subject: Re: [RFC PATCH v1 0/7] Introduction of PSCR Framework and Related
 Components

Hi,

On Fri, Jan 19, 2024 at 02:25:14PM +0100, Oleksij Rempel wrote:
> This patch series introduces the Power State Change Reasons (PSCR)
> tracking framework and its related components into the kernel. The PSCR
> framework is designed for systems where traditional methods of storing
> power state change reasons, like PMICs or watchdogs, are inadequate. It
> provides a structured way to store reasons for system shutdowns and
> reboots, such as under-voltage or software-triggered events, in
> non-volatile hardware storage.
> 
> These changes are critical for systems requiring detailed postmortem
> analysis and where immediate power-down scenarios limit traditional
> storage options. The framework also assists bootloaders and early-stage
> system components in making informed recovery decisions.

A couple of things come to my mind:

1. Do we need the DT based reason-string-to-integer mapping? Can we
   just use a fixed mapping instead? It simplifies the binding a
   lot. With that the generic part could be dropped completely.

2. I would expect the infrastructure to read and clear the reason
   during boot. If e.g. a watchdog triggers a reset you will otherwise
   get an incorrect value.

3. The reason is only stored, but not used? We have a sysfs ABI to
   expose the reboot reason to userspace since half a year ago, see
   d40befed9a58 (power: reset: at91-reset: add sysfs interface to
   the power on reason).

4. Available options should be synced with the list in
   include/linux/power/power_on_reason.h

-- Sebastian

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)