Re: [PATCH v2 2/3] power: reset: pscrr: add watchdog pretimeout reason tracking

Guenter Roeck <[email protected]> Thu, 30 Jul 2026 08:02:35 -0700
Newsgroups org.kernel.vger.linux-watchdog,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pm
Message-ID <[email protected]>
On 7/29/26 22:24, Oleksij Rempel wrote:
> Hi Matti,
> 
> On Thu, Jul 30, 2026 at 07:49:41AM +0300, Matti Vaittinen wrote:
>> On 22/07/2026 18:13, Faruque Ansari wrote:
>>> Watchdog pretimeout resets are not recorded with a dedicated reset
>>> reason, causing subsequent boots to report PSCR_UNKNOWN and making it
>>> difficult to distinguish them from other unexpected resets.
>>>
>>> Add PSCR_WATCHDOG_PRETIMEOUT as a dedicated reset reason code and
>>> prevent the panic notifier from overwriting a watchdog pretimeout
>>> reason with PSCR_KERNEL_PANIC when the pretimeout governor triggers a
>>> panic.
>>>
>>> Signed-off-by: Faruque Ansari <[email protected]>
>>> ---
>>>    drivers/power/reset/pscrr.c           | 7 ++++++-
>>>    include/linux/power/power_on_reason.h | 1 +
>>>    include/linux/reboot.h                | 1 +
>>>    kernel/reboot.c                       | 1 +
>>>    4 files changed, 9 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/power/reset/pscrr.c b/drivers/power/reset/pscrr.c
>>> index b5906f127e88..5b107c62fe82 100644
>>> --- a/drivers/power/reset/pscrr.c
>>> +++ b/drivers/power/reset/pscrr.c
>>> @@ -149,7 +149,12 @@ static int pscrr_panic_notifier(struct notifier_block *nb,
>>>    	if (!backend || !backend->ops || !backend->ops->write_reason)
>>>    		return NOTIFY_OK;
>>> -	set_psc_reason(PSCR_KERNEL_PANIC);
>>> +	/*
>>> +	 * Do not overwrite a previously recorded watchdog pretimeout reason
>>> +	 * during panic handling.
>>> +	 */
>>> +	if (get_psc_reason() != PSCR_WATCHDOG_PRETIMEOUT)
>>> +		set_psc_reason(PSCR_KERNEL_PANIC);
>>
>> Hi Faruque,
>>
>> I like the idea of adding WDG pretimeout resets in pscrr. I am just
>> wondering what makes WDG reason so special, that it shouldn't be overwritten
>> while other reasons can be? Can this notifier be called (now or in the
>> future) so, that there are other reasons getting overwritten? For some
>> reason I think the PSCRR was designed to be able to store multiple
>> reasons(?)
> 
> It depends on the backed. A simple nvmem cell, would be able to hold
> only one reason.
> 

That makes me wonder: Shouldn't the priority be a back-end decision, not a
front-end decision ?

Guenter