From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: "Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Srinivas Kandagatla" <srinivas.kandagatla@linaro.org>,
kernel@pengutronix.de, linux-kernel@vger.kernel.org,
"Liam Girdwood" <lgirdwood@gmail.com>,
"Mark Brown" <broonie@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Daniel Lezcano" <daniel.lezcano@linaro.org>,
"Zhang Rui" <rui.zhang@intel.com>,
"Lukasz Luba" <lukasz.luba@arm.com>,
linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
"Søren Andersen" <san@skov.dk>
Subject: Re: [RFC PATCH v1 0/7] Introduction of PSCR Framework and Related Components
Date: Sun, 21 Jan 2024 07:56:10 +0100 [thread overview]
Message-ID: <20240121065610.GC163482@pengutronix.de> (raw)
In-Reply-To: <7gadkjffeljjwb2cgcmg6ixco3xtg4t4hrxtetfnjyzuxvfsjt@ze7u4glqnerb>
Hi,
On Sat, Jan 20, 2024 at 12:19:09AM +0100, Sebastian Reichel wrote:
> 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.
The project I'm working is using RTC for storage. The RTC device in
question provides 8 bits, 3 bits are assigned for PSCR.
Currently all reasons provided in this patch set would fit int to 3 bits,
but soon or later it may expand.
> 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.
Hm.. good point. I'll set a value on the boot that there is currently no
attempt to shutdown at all. PSCR works only for software assisted
shutdown/reboot. It should extend, not replace PMIC or watchdog detected
reasons.
> 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).
ACK. I'll add sysfs support.
For my use case, the user is the bootloader. The is one of reasons why
DT is used for mappings, this is the stable ABI between this systems.
> 4. Available options should be synced with the list in
> include/linux/power/power_on_reason.h
ACK
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
prev parent reply other threads:[~2024-01-21 6:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-19 13:25 [RFC PATCH v1 0/7] Introduction of PSCR Framework and Related Components Oleksij Rempel
2024-01-19 13:25 ` [RFC PATCH v1 1/7] dt-bindings: power: reset: add generic PSCR binding trackers Oleksij Rempel
2024-01-19 14:50 ` Rob Herring
2024-01-19 17:28 ` Rob Herring
2024-01-19 17:54 ` Oleksij Rempel
2024-01-19 13:25 ` [RFC PATCH v1 2/7] power: reset: Introduce PSCR Tracking Framework for Non-Volatile Storage Oleksij Rempel
2024-01-19 13:25 ` [RFC PATCH v1 3/7] dt-bindings: power: reset: add bindings for NVMEM hardware storing PSCR Data Oleksij Rempel
2024-01-19 14:50 ` Rob Herring
2024-01-19 13:25 ` [RFC PATCH v1 4/7] nvmem: provide consumer access to cell size metrics Oleksij Rempel
2024-01-19 13:25 ` [RFC PATCH v1 5/7] power: reset: add PSCR NVMEM Driver for Storing Power State Change Reasons Oleksij Rempel
2024-01-19 13:25 ` [RFC PATCH v1 6/7] regulator: set Power State Change Reason before hw_protection_shutdown() Oleksij Rempel
2024-01-19 14:07 ` Mark Brown
2024-01-19 13:25 ` [RFC PATCH v1 7/7] thermal: core: " Oleksij Rempel
2024-01-19 18:34 ` Rafael J. Wysocki
2024-01-19 19:34 ` Oleksij Rempel
2024-01-19 20:11 ` Rafael J. Wysocki
2024-01-19 23:19 ` [RFC PATCH v1 0/7] Introduction of PSCR Framework and Related Components Sebastian Reichel
2024-01-21 6:56 ` Oleksij Rempel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240121065610.GC163482@pengutronix.de \
--to=o.rempel@pengutronix.de \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=kernel@pengutronix.de \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
--cc=rui.zhang@intel.com \
--cc=san@skov.dk \
--cc=sebastian.reichel@collabora.com \
--cc=srinivas.kandagatla@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox