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

[Faruque Ansari <faruque.ansari@oss.qualcomm.com>]

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@oss.qualcomm.com/

Thanks,
Faruque Ansari

> 
> [ ... ]