Re: [PATCH v2 3/3] watchdog: pretimeout: record PSC reason on watchdog pretimeout

[Faruque Ansari <faruque.ansari@oss.qualcomm.com>]

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@oss.qualcomm.com>
>> ---
>>   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