| Message ID | 20240119132521.3609945-1-o.rempel@pengutronix.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | Introduction of PSCR Framework and Related Components | expand |
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
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
Hello all, 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. Oleksij Rempel (7): dt-bindings: power: reset: add generic PSCR binding trackers power: reset: Introduce PSCR Tracking Framework for Non-Volatile Storage dt-bindings: power: reset: add bindings for NVMEM hardware storing PSCR Data nvmem: provide consumer access to cell size metrics power: reset: add PSCR NVMEM Driver for Storing Power State Change Reasons regulator: set Power State Change Reason before hw_protection_shutdown() thermal: core: set Power State Change Reason before hw_protection_shutdown() .../bindings/power/reset/pscr-nvmem.yaml | 54 ++++ .../devicetree/bindings/power/reset/pscr.yaml | 51 ++++ drivers/nvmem/core.c | 25 ++ drivers/power/reset/Kconfig | 30 ++ drivers/power/reset/Makefile | 2 + drivers/power/reset/pscr-nvmem.c | 100 +++++++ drivers/power/reset/pscr.c | 259 ++++++++++++++++++ drivers/regulator/core.c | 6 + drivers/thermal/thermal_core.c | 2 + include/linux/nvmem-consumer.h | 7 + include/linux/pscr.h | 40 +++ 11 files changed, 576 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/reset/pscr-nvmem.yaml create mode 100644 Documentation/devicetree/bindings/power/reset/pscr.yaml create mode 100644 drivers/power/reset/pscr-nvmem.c create mode 100644 drivers/power/reset/pscr.c create mode 100644 include/linux/pscr.h