changes v11:
- add missing break reported by kernel test robot <lkp@intel.com>

changes v10:
- add some add Reviewed-by tags
- regulator_handle_critical: set pscr = PSCR_UNKNOWN for default case
- make g_pscrr static

changes v9:
- Remove redundant pr_crit() messages before hw_protection_trigger()
- Replace psc_reason_to_str() switch with static const string array
- Mark psc_last_reason as static

changes v8:
- Use DEFINE_GUARD() and guard(g_pscrr) for scoped locking of the global
  pscrr_core struct
- Replace manual mutex_lock/unlock with automatic cleanup-based guard()
  usage
- Centralize backend and locking state in struct pscrr_core
- Prepare for future multi-backend support with clean encapsulation
- Improve sysfs documentation:
  * Added full enum psc_reason value table
  * Simplified example comments, removed redundant "may differ" phrasing
  * Added note that not all values are supported on all systems
  * Linked value definitions to include/linux/reboot.h
  * Added clear read/write usage examples for sysfs entries

changes v7:
- document expected values in sysfs documentation
- make write support optional

changes v6:
- add sysfs documentation
- rebase against latest hw_protection_reboot changes:
  https://web.git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-nonmm-unstable&id=212dd3f6e57f6af8ed3caa23b93adc29334f9652
- push core part of the reset reason the kernel/reboot.c

changes v5:
- fix compile with NVMEM=n and potential issues with NVMEM=m

changes v4:
- fix compile with CONFIG_PSCRR=n

changes v3
- rework to remove devicetree dependencies
- extend NVMEM to search devices and cells by names.

changes v2:
- rename the framework from PSCR to PSCRR (last R is for Recorder)
- extend power on reason header and use it to show detected reason on
  system start and in sysfs.
- remove "unknow" reason
- rebase on top of v6.8-rc1
- yaml fixes
- zero reason state on boot

Hello all,

This patch series introduces the Power State Change Reasons Recording
(PSCRR) 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):
  power: Extend power_on_reason.h for upcoming PSCRR framework
  reboot: hw_protection_trigger: use standardized numeric
    shutdown/reboot reasons instead of strings
  power: reset: Introduce PSCR Recording Framework for Non-Volatile
    Storage
  nvmem: provide consumer access to cell size metrics
  nvmem: add support for device and sysfs-based cell lookups
  power: reset: add PSCR NVMEM Driver for Recording Power State Change
    Reasons
  Documentation: Add sysfs documentation for PSCRR reboot reason
    tracking

 .../ABI/testing/sysfs-kernel-reboot-pscrr     |  74 ++++
 drivers/nvmem/core.c                          | 134 ++++++
 drivers/platform/chrome/cros_ec_lpc.c         |   2 +-
 drivers/power/reset/Kconfig                   |  47 ++
 drivers/power/reset/Makefile                  |   2 +
 drivers/power/reset/pscrr-nvmem.c             | 254 +++++++++++
 drivers/power/reset/pscrr.c                   | 405 ++++++++++++++++++
 drivers/regulator/core.c                      |  16 +-
 drivers/regulator/irq_helpers.c               |   9 +-
 drivers/thermal/thermal_core.c                |   3 +-
 include/linux/nvmem-consumer.h                |  25 ++
 include/linux/power/power_on_reason.h         |   4 +
 include/linux/pscrr.h                         |  58 +++
 include/linux/reboot.h                        |  77 +++-
 kernel/reboot.c                               |  85 +++-
 15 files changed, 1173 insertions(+), 22 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-kernel-reboot-pscrr
 create mode 100644 drivers/power/reset/pscrr-nvmem.c
 create mode 100644 drivers/power/reset/pscrr.c
 create mode 100644 include/linux/pscrr.h

--
2.39.5

Hi Greg,

this patch series doesn’t belong to any single existing subsystem. It
spans drivers like power/reset/, touches nvmem, regulator, and adds new
interfaces.

Since there's no clear maintainer fit and the code is self-contained,
I’d like to ask you to pick it up.

The latest version is v11 and has addressed all review comments.

Thanks!
Oleksij

On Wed, Jun 18, 2025 at 02:02:48PM +0200, Oleksij Rempel wrote:
> changes v11:
> - add missing break reported by kernel test robot <lkp@intel.com>
> 
> changes v10:
> - add some add Reviewed-by tags
> - regulator_handle_critical: set pscr = PSCR_UNKNOWN for default case
> - make g_pscrr static
> 
> changes v9:
> - Remove redundant pr_crit() messages before hw_protection_trigger()
> - Replace psc_reason_to_str() switch with static const string array
> - Mark psc_last_reason as static
> 
> changes v8:
> - Use DEFINE_GUARD() and guard(g_pscrr) for scoped locking of the global
>   pscrr_core struct
> - Replace manual mutex_lock/unlock with automatic cleanup-based guard()
>   usage
> - Centralize backend and locking state in struct pscrr_core
> - Prepare for future multi-backend support with clean encapsulation
> - Improve sysfs documentation:
>   * Added full enum psc_reason value table
>   * Simplified example comments, removed redundant "may differ" phrasing
>   * Added note that not all values are supported on all systems
>   * Linked value definitions to include/linux/reboot.h
>   * Added clear read/write usage examples for sysfs entries
> 
> changes v7:
> - document expected values in sysfs documentation
> - make write support optional
> 
> changes v6:
> - add sysfs documentation
> - rebase against latest hw_protection_reboot changes:
>   https://web.git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-nonmm-unstable&id=212dd3f6e57f6af8ed3caa23b93adc29334f9652
> - push core part of the reset reason the kernel/reboot.c
> 
> changes v5:
> - fix compile with NVMEM=n and potential issues with NVMEM=m
> 
> changes v4:
> - fix compile with CONFIG_PSCRR=n
> 
> changes v3
> - rework to remove devicetree dependencies
> - extend NVMEM to search devices and cells by names.
> 
> changes v2:
> - rename the framework from PSCR to PSCRR (last R is for Recorder)
> - extend power on reason header and use it to show detected reason on
>   system start and in sysfs.
> - remove "unknow" reason
> - rebase on top of v6.8-rc1
> - yaml fixes
> - zero reason state on boot
> 
> Hello all,
> 
> This patch series introduces the Power State Change Reasons Recording
> (PSCRR) 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):
>   power: Extend power_on_reason.h for upcoming PSCRR framework
>   reboot: hw_protection_trigger: use standardized numeric
>     shutdown/reboot reasons instead of strings
>   power: reset: Introduce PSCR Recording Framework for Non-Volatile
>     Storage
>   nvmem: provide consumer access to cell size metrics
>   nvmem: add support for device and sysfs-based cell lookups
>   power: reset: add PSCR NVMEM Driver for Recording Power State Change
>     Reasons
>   Documentation: Add sysfs documentation for PSCRR reboot reason
>     tracking
> 
>  .../ABI/testing/sysfs-kernel-reboot-pscrr     |  74 ++++
>  drivers/nvmem/core.c                          | 134 ++++++
>  drivers/platform/chrome/cros_ec_lpc.c         |   2 +-
>  drivers/power/reset/Kconfig                   |  47 ++
>  drivers/power/reset/Makefile                  |   2 +
>  drivers/power/reset/pscrr-nvmem.c             | 254 +++++++++++
>  drivers/power/reset/pscrr.c                   | 405 ++++++++++++++++++
>  drivers/regulator/core.c                      |  16 +-
>  drivers/regulator/irq_helpers.c               |   9 +-
>  drivers/thermal/thermal_core.c                |   3 +-
>  include/linux/nvmem-consumer.h                |  25 ++
>  include/linux/power/power_on_reason.h         |   4 +
>  include/linux/pscrr.h                         |  58 +++
>  include/linux/reboot.h                        |  77 +++-
>  kernel/reboot.c                               |  85 +++-
>  15 files changed, 1173 insertions(+), 22 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-kernel-reboot-pscrr
>  create mode 100644 drivers/power/reset/pscrr-nvmem.c
>  create mode 100644 drivers/power/reset/pscrr.c
>  create mode 100644 include/linux/pscrr.h
> 
> --
> 2.39.5
> 
> 

-- 
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 |

On Mon, Jul 14, 2025 at 12:17:48PM +0200, Oleksij Rempel wrote:
> Hi Greg,
> 
> this patch series doesn’t belong to any single existing subsystem. It
> spans drivers like power/reset/, touches nvmem, regulator, and adds new
> interfaces.
> 
> Since there's no clear maintainer fit and the code is self-contained,
> I’d like to ask you to pick it up.
> 
> The latest version is v11 and has addressed all review comments.

I have some comments as I haven't reviewed this yet :)

Let me go download the series and respond to what I found...

thanks,

greg k-h

Hi all,

I'm seeking consensus on a minimal, upstream-acceptable way to identify the
single NVMEM cell used to persist a Power State Change Reason (PSCR). Typical
targets are battery-backed RTC scratchpads or small EEPROM. The aim is to have
a tiny breadcrumb available before userspace, across full power cuts, and
shared by bootloader/kernel/userspace.

DT vs Userspace vs ACPI

* DeviceTree (preferred): Describing where the storage lives under a real
  NVMEM provider (RTC/EEPROM) is early, robust, and OS-agnostic.

* Userspace (fallback): Possible via module/cmdline/sysfs, but leaves an
  early-boot window unconfigured and reduces usefulness for embedded devices.

* ACPI: No existing shared mechanism for this use case at present (not
  proposing an ACPI path right now).

What implementations were tried

* A PSCR consumer node in DT -> NACKed as not a HW node.

* Kernel/module parameters or sysfs selection -> tried earlier, but rejected
  for new designs and cannot guarantee early availability.

* Name-based lookups in NVMEM -> considered fragile and not scalable.

Other options which came in question (seeking guidance)

* cell-level `compatible` on a fixed-cell child (analogous to `mac-base`) to
  nominate the PSCR cell under the existing NVMEM provider. DT remains purely
  descriptive (location/size); encoding is documented outside DT and shared
  across components.

* `/chosen` phandle pointing to the nominated fixed-cell (simple to discover;
  unsure about policy concerns).

* pstore integration (not tried): a backend that uses a nominated NVMEM cell if
  such a nomination is acceptable.

* nvmem-layout usage (not tried): provider-side markup of the region to
  indicate it carries PSCR, if that pattern is acceptable for this purpose.

* Open to any established precedent for nominating a specific NVMEM cell for a
  system role without introducing software/virtual DT nodes.

Ask

* Is a cell-level `compatible` on a `fixed-cell` child an acceptable way to
  nominate the PSCR cell?

* If not, is a `/chosen` phandle acceptable here, or is there a preferred
  alternative?

Thanks for guidance - once the selection mechanism is agreed, I can respin the
PSCR series accordingly.

Latest patch version: https://lore.kernel.org/all/aHTZTFxfS6Bn4yhz@pengutronix.de/

Best 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 |

On Thu, Oct 02, 2025 at 02:00:09PM +0200, Oleksij Rempel wrote:
> I'm seeking consensus on a minimal, upstream-acceptable way to identify the
> single NVMEM cell used to persist a Power State Change Reason (PSCR). Typical
> targets are battery-backed RTC scratchpads or small EEPROM. The aim is to have
> a tiny breadcrumb available before userspace, across full power cuts, and
> shared by bootloader/kernel/userspace.
> [...]
> * pstore integration (not tried): a backend that uses a nominated NVMEM cell if
>   such a nomination is acceptable.

Several years ago I wanted to have tighter integration between pstore
and nvdimm code. The thread is here, for reference:
https://lore.kernel.org/lkml/CAGXu5jLtmb3qinZnX3rScUJLUFdf+pRDVPjy=CS4KUtW9tLHtw@mail.gmail.com/

I'm not sure it it'll be a useful as background, but I thought I'd
mention it. :)

-Kees

-- 
Kees Cook