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

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.

> Could you just add one more instead of overwriting existing - or
> should the check be more generic (to ensure the reason is only set if there
> is nothing to overwrite).

So, depending on the backed, we will have different policies. For
example, with one slot storage, we need to decided what to store:
first one or the last one.

In most cases, the initial one is most interesting. But, if we are
debugging system reset/reboot behavior, the last one.

> 
> If I am just completely lost (which happens), could you then improve the
> comment a bit to explain why WDG timeout is special and shouldn't be
> overwritten. The checking code itself is quite self-explatonary ;)

Good question. I included this patch to my refactoring, but didn't had
strong opinion haw to handle it. I guess, after introducing record
policy, this issue will be partially addressed:

https://github.com/olerem/linux-2.6/blob/v7.2/topic/pscr/Documentation/ABI/testing/sysfs-kernel-pscrr#L95

-- 
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 |