All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Sebastian Reichel <sre@kernel.org>,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Benson Leung <bleung@chromium.org>,
	Tzung-Bi Shih <tzungbi@kernel.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>, Kees Cook <kees@kernel.org>,
	Tony Luck <tony.luck@intel.com>,
	"Guilherme G. Piccoli" <gpiccoli@igalia.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: kernel@pengutronix.de, linux-kernel@vger.kernel.org,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	"Mark Brown" <broonie@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Zhang Rui" <rui.zhang@intel.com>,
	"Lukasz Luba" <lukasz.luba@arm.com>,
	linux-pm@vger.kernel.org, "Søren Andersen" <san@skov.dk>,
	"Guenter Roeck" <groeck@chromium.org>,
	"Matti Vaittinen" <mazziesaccount@gmail.com>,
	"Ahmad Fatoum" <a.fatoum@pengutronix.de>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	chrome-platform@lists.linux.dev, devicetree@vger.kernel.org,
	linux-hardening@vger.kernel.org
Subject: RFC: Selecting an NVMEM cell for Power State Change Reason (PSCR) recording
Date: Thu, 2 Oct 2025 14:00:09 +0200	[thread overview]
Message-ID: <aN5pSWBFRZlNRv3U@pengutronix.de> (raw)
In-Reply-To: <20250618120255.3141862-1-o.rempel@pengutronix.de>

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 |

  parent reply	other threads:[~2025-10-02 12:00 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-18 12:02 [PATCH v11 0/7] Introduction of PSCR Framework and Related Components Oleksij Rempel
2025-06-18 12:02 ` [PATCH v11 1/7] power: Extend power_on_reason.h for upcoming PSCRR framework Oleksij Rempel
2025-06-18 12:02 ` [PATCH v11 2/7] reboot: hw_protection_trigger: use standardized numeric shutdown/reboot reasons instead of strings Oleksij Rempel
2025-06-18 12:02 ` [PATCH v11 3/7] power: reset: Introduce PSCR Recording Framework for Non-Volatile Storage Oleksij Rempel
2025-07-16 12:43   ` Greg KH
2025-06-18 12:02 ` [PATCH v11 4/7] nvmem: provide consumer access to cell size metrics Oleksij Rempel
2025-06-18 12:02 ` [PATCH v11 5/7] nvmem: add support for device and sysfs-based cell lookups Oleksij Rempel
2025-07-16 12:48   ` Greg KH
2025-06-18 12:02 ` [PATCH v11 6/7] power: reset: add PSCR NVMEM Driver for Recording Power State Change Reasons Oleksij Rempel
2025-06-20 15:56   ` Francesco Valla
2025-07-16 12:51   ` Greg KH
2026-06-25 11:52   ` Faruque Ansari
2025-06-18 12:02 ` [PATCH v11 7/7] Documentation: Add sysfs documentation for PSCRR reboot reason tracking Oleksij Rempel
2025-07-14 10:17 ` [PATCH v11 0/7] Introduction of PSCR Framework and Related Components Oleksij Rempel
2025-07-16 12:34   ` Greg Kroah-Hartman
2025-10-02 12:00 ` Oleksij Rempel [this message]
2025-10-02 16:07   ` RFC: Selecting an NVMEM cell for Power State Change Reason (PSCR) recording Kees Cook
2026-03-10  9:29     ` [PR 174] dt-bindings: chosen: Add "power-state-change-reason" nvmem property Oleksij Rempel
     [not found] ` <3309e88e-e189-42ea-b74e-346aec1b4b5f@oss.qualcomm.com>
2026-06-29 11:14   ` [PATCH v11 0/7] Introduction of PSCR Framework and Related Components Faruque Ansari
2026-06-29 11:41     ` Oleksij Rempel
2026-07-01 12:56       ` Faruque Ansari
2026-07-02  4:21         ` Oleksij Rempel
2026-07-06  9:36           ` Faruque Ansari

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=aN5pSWBFRZlNRv3U@pengutronix.de \
    --to=o.rempel@pengutronix.de \
    --cc=a.fatoum@pengutronix.de \
    --cc=akpm@linux-foundation.org \
    --cc=bleung@chromium.org \
    --cc=broonie@kernel.org \
    --cc=chrome-platform@lists.linux.dev \
    --cc=conor+dt@kernel.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gpiccoli@igalia.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=groeck@chromium.org \
    --cc=kees@kernel.org \
    --cc=kernel@pengutronix.de \
    --cc=krzk+dt@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=mazziesaccount@gmail.com \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=san@skov.dk \
    --cc=sre@kernel.org \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=tony.luck@intel.com \
    --cc=tzungbi@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.