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

On Thu, Jul 30, 2026 at 08:02:35AM -0700, Guenter Roeck wrote:
> 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 ?

Backend provides capabilities, most nvmem cells will be able to store
only one record. Which record matters (first or last) is a
use/investigation case specific policy. 

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