dt-bindings: chosen: Add "power-state-change-reason" nvmem property#174
dt-bindings: chosen: Add "power-state-change-reason" nvmem property#174olerem wants to merge 1 commit into
Conversation
A lot of systems (especially embedded) store the last shutdown/reboot
reason in NVMEM. This could be anything from "over temperature" or
"brown-out" to an "EC panic" or watchdog reset.
There's currently no standard way for firmware to tell the kernel where
to find this information.
The /chosen node is already used for passing global, firmware-provided
data like 'bootargs' and 'stdout-path'. Let's use it for this, too.
This patch adds a binding for a new generic NVMEM cell name in /chosen:
"power-state-change-reason".
Example from the binding:
chosen {
nvmem-cells = <&pscr_cell>;
nvmem-cell-names = "power-state-change-reason";
};
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
olerem
changed the title
|
This works if the OS controls the value in nvmem, but if the value for various reasons is platform specific, then you need some driver to interpret it. In that case you wouldn't want this in /chosen. There's also the related reboot-mode.yaml and nvmem-reboot-mode.yaml bindings in the kernel tree. Not sure if those could/should be extended with the reason? |
|
Hi @robherring , Moving this to a dedicated node brings us back to my initial proposal (v3) [1], which used a dedicated node to map these values. That proposal was rejected at the time as being "OS policy" rather than hardware description. If I bring back the dedicated node approach (based on your reboot-mode suggestion), would you (and Krzysztof) agree to accept it as a description of the firmware contract (defining the value-to-reason mapping)? I want to ensure we have consensus on the approach before I reimplement the binding. [1] https://lore.kernel.org/all/20240124122204.730370-5-o.rempel@pengutronix.de/ |
2 participants
Hi all,
I'm proposing a new generic property for the /chosen node to identify
an NVMEM cell containing the last system shutdown/reboot reason. Many
embedded systems record this (e.g., "over-temperature", "brown-out"),
but there's no standard way to pass this location to the OS.
I'm sending this as an RFC patch because I'm uncertain about a few points:
Is the /chosen node the right conceptual place for
this? It feels correct for a global, firmware-provided property,
much like 'stdout-path', but I'd
like to be sure.
Is this the right file to patch (
chosen.yaml)? Or should thisbe defined in a more central NVMEM binding?
Are the '$ref's correct? I'm referencing the existing meta-schema
nvmem.yaml from schema (feels wrong). Is this the standard way to re-use
properties from another schema?
Any feedback on the approach or the implementation would be greatly appreciated.
Thanks,
Oleksij