Re: [PATCH v15 5/6] power: reset: Introduce PSCR Recording Framework for Non-Volatile Storage

[Faruque Ansari]

Hi Daniel Lezcano,

On 02-Oct-26 2:36 PM, Daniel Lezcano wrote:
> On Thu, Sep 24, 2026 at 12:38:46PM +0530, Faruque Ansari wrote:
> > Introduce the Power State Change Reasons Recording (PSCRR) framework: a
> > generic mechanism to record why the last power state change (shutdown or
> > reboot) happened - under-voltage, thermal, watchdog, software-triggered,
> > etc. - so a postmortem reason survives a reboot or an abrupt power loss.
> >
> > PSCRR is built around providers. A provider is either a hardware reason
> > source (a PMIC, SoC reset controller or watchdog exposing a reset cause)
> > or a recorder that persists the reason across a power cycle (an NVMEM or
> > RTC scratch cell). Each provider gets a directory under
> > /sys/kernel/pscrr/providerN/ exposing its name, backing device, the set
> > of observed reasons (as tokens), its capabilities, the reasons it
> > supports and - for recorders - a record policy. The reason set is
> > deliberately not collapsed to a single winning cause, since resets are
> > often multi-causal.
> >
> > Reasons are the numeric enum psc_reason values from reboot.h, shared with
> > the POWER_ON_REASON_* vocabulary, so they store compactly in small
> > battery-backed cells. The current reason (get/set_psc_reason(), set by
> > the thermal/regulator/hw_protection paths) is written to every recorder
> > from the reboot notifier.
>
> [ ... ]
>
> > +menuconfig PSCRR
> > +	bool "Power State Change Reasons Recording (PSCRR) Framework"
> > +	depends on POWER_RESET
> > +	help
> > +	  Enables the Power State Change Reasons Recording (PSCRR) framework.
> > +
> > +	  PSCRR records why the system last shut down or rebooted into
> > +	  non-volatile storage, so the reason survives the reset and can be
> > +	  read by the bootloader or early user space on the next boot. Reasons
> > +	  come from software (thermal or regulator hardware-protection events,
> > +	  a watchdog pretimeout, a kernel panic, a controlled reboot) or from
> > +	  hardware reset-cause registers (PMIC, SoC reset controller, watchdog).
>
> [ ... ]
>
> > +static int pscrr_reboot_notifier(struct notifier_block *nb,
> > +				 unsigned long action, void *unused)
> > +{
> > +	guard(mutex)(&pscrr_lock);
> > +
> > +	/*
> > +	 * A reboot, halt or power-off that reaches here with no more specific
> > +	 * reason is software-initiated by definition. Record it as such rather
> > +	 * than leaving it unattributed; a real cause set earlier (thermal,
> > +	 * under-voltage, ...) is already latched and left untouched.
> > +	 */
> > +	if (get_psc_reason() == PSCR_UNKNOWN)
> > +		set_psc_reason(PSCR_SOFTWARE);
> > +
> > +	pscrr_record_current();
> > +
> > +	return NOTIFY_DONE;
> > +}
> > +
> > +static struct notifier_block pscrr_reboot_nb = {
> > +	.notifier_call = pscrr_reboot_notifier,
> > +};
>
> I'm worried about the mechanism. The call to set_psc_reason() sets a
> global variable and pscrr_record_current() write its value to the
> NVMEM backend.
>
> That is done from the reboot notifier.
>
> Is this notifier called in all cases, eg. watchdog reset or emergency
> reboot ? It sounds possible the reason is set but then the notifier is
> not called thus not written in the non-volatile medium, no ?

Ack.
Thanks for your review.

You're right. The current core series reliably records only 
orderly reboot/shutdown paths via the reboot notifier chain; 
emergency_restart() bypasses it, so the reason may be set but not 
recorded.

Panic-driven emergency reboots (e.g. sysrq-c and watchdog 
pretimeout panic) are addressed by my follow-up v3 series [1], 
which records the reset cause via panic_notifier_list before 
panic() reaches emergency_restart().

For true hardware resets (e.g. watchdog bite, brownout, or 
external reset), no Linux code executes, so software recording is 
not possible. Those cases are expected to be handled by PMIC/SoC 
reset-cause providers on the subsequent boot. The PMIC 
reset-cause provider is planned to be posted as a separate series 
once NVMEM provider support is accepted.

[1] 
https://lore.kernel.org/all/20260804-pscrr-reboot-reason-v3-0-e706dbfc7465@xxxxxxxxxxxxxxxx/

Thanks,
Faruque Ansari

> [ ... ]