Re: [PATCH v2 3/3] watchdog: pretimeout: record PSC reason on watchdog pretimeout
From: Faruque Ansari
Date: Thu Jul 30 2026 - 06:44:00 EST
Hi Guenter,
On 30-Jul-26 10:33 AM, Guenter Roeck wrote:
On 7/22/26 08:13, Faruque Ansari wrote:Thanks for reviewing.
Update the PSC reset reason by invoking set_psc_reason(PSCR_WATCHDOG_PRETIMEOUT)
from watchdog_notify_pretimeout() before either the panic or noop governor
runs, so the reset cause is committed to persistent storage before the
system goes down.
Signed-off-by: Faruque Ansari <faruque.ansari@xxxxxxxxxxxxxxxx>
---
drivers/watchdog/watchdog_pretimeout.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/watchdog/watchdog_pretimeout.c b/drivers/ watchdog/watchdog_pretimeout.c
index 02e09b9e396d..ea48d4eca4aa 100644
--- a/drivers/watchdog/watchdog_pretimeout.c
+++ b/drivers/watchdog/watchdog_pretimeout.c
@@ -4,6 +4,7 @@
*/
#include <linux/list.h>
+#include <linux/reboot.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
#include <linux/string.h>
@@ -103,6 +104,8 @@ void watchdog_notify_pretimeout(struct watchdog_device *wdd)
{
unsigned long flags;
+ set_psc_reason(PSCR_WATCHDOG_PRETIMEOUT);
+
A call to watchdog_notify_pretimeout() does not necessarily reset the system.
It only resets the system if the panic governor is active. Given that,
I think this is a bit misleading. If the "noop" governor is active and the
system crashes later due to a completely unrelated panic, the restart reason
will be wrongly logged as pretimeout.
I agree. My intention was to handle both governors through the common pretimeout path. However, with the "noop" governor the recorded reason may be misleading since the system can continue running.
I'll move the recording to the panic governor path in the next version.
Thanks,
Faruque Ansari