RFC: Selecting an NVMEM cell for Power State Change Reason (PSCR) recording

RFC: Selecting an NVMEM cell for Power State Change Reason (PSCR) recording

[Oleksij Rempel]

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 |

Re: RFC: Selecting an NVMEM cell for Power State Change Reason (PSCR) recording

[Kees Cook]

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

Re: [PR 174] dt-bindings: chosen: Add "power-state-change-reason" nvmem property

[Oleksij Rempel]

Hi Rob and Krzysztof,

Following up on dt-schema PR #174 regarding the PSCRR framework. We are
currently stuck in a maintainer deadlock regarding how this framework should
bind to its NVMEM cell, and I need your consensus to proceed.

In the PR [1], Rob noted that /chosen only works if the OS standardizes the
NVMEM values. If the values are platform-specific (requiring a mapping driver),
Rob suggested creating a dedicated DT node akin to reboot-mode or
nvmem-reboot-mode.

However, in my earlier kernel patchsets [2] , Krzysztof explicitly NACKed a
dedicated PSCRR DT node, stating that it represents "OS policy" and a software
abstraction rather than physical hardware. Krzysztof suggested instantiating it
via sysfs/modprobe. I attempted that in v11 , but Greg strongly rejected [3]
the sysfs/module parameter approach as fragile and outdated for the driver
core.

We need a robust way to discover this cell during early boot across full power
cuts. To break this catch-22, could you please agree on one of the following?

- Option A (Dedicated DT node): Permit a dedicated pscrr-nvmem node (or a
compatible string on a fixed-cell) as a valid firmware description contract,
following the precedent of nvmem-reboot-mode.

- Option B (/chosen property): Accept the /chosen phandle approach

I am happy to implement whichever hardware/software binding pattern you both
agree is correct for this edge case.

Best Regards,
Oleksij

[1] https://github.com/devicetree-org/dt-schema/pull/174
[2] https://lore.kernel.org/all/58d24ddc-4e8f-4932-ac37-c9a699d36425@linaro.org/
[3] https://lore.kernel.org/all/2025071631-henna-synthesis-9961@gregkh/ 

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