From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "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>,
"Conor Dooley" <conor+dt@kernel.org>,
"Tony Luck" <tony.luck@intel.com>,
"Guilherme G. Piccoli" <gpiccoli@igalia.com>,
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, "Kees Cook" <kees@kernel.org>
Subject: Re: [PR 174] dt-bindings: chosen: Add "power-state-change-reason" nvmem property
Date: Tue, 10 Mar 2026 10:29:21 +0100 [thread overview]
Message-ID: <aa_kcRRg5uGQjd96@pengutronix.de> (raw)
In-Reply-To: <202510020904.1E48B7EB@keescook>
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 |
prev parent reply other threads:[~2026-03-10 9:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250618120255.3141862-1-o.rempel@pengutronix.de>
2025-10-02 12:00 ` RFC: Selecting an NVMEM cell for Power State Change Reason (PSCR) recording Oleksij Rempel
2025-10-02 16:07 ` Kees Cook
2026-03-10 9:29 ` 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=aa_kcRRg5uGQjd96@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox