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