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

Thanks for reviewing.
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