From: sashiko-bot@kernel.org
To: zoan37 <agentzoan@gmail.com>
Cc: linux-watchdog@vger.kernel.org
Subject: Re: [PATCH v2] watchdog: mtk_wdt: Stop a running watchdog over system sleep even if not opened
Date: Sun, 11 Oct 2026 01:29:26 +0000 [thread overview]
Message-ID: <sashiko-outbox-166960@kernel.org> (raw)
In-Reply-To: <20261011011536.1139162-1-agentzoan@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] watchdog: system reset during suspend_freeze_processes() due to prematurely stopped ping worker
--
commit 49206fab5f9c9b345c52cba7a65df971c5a0d992
Author: zoan37 <agentzoan@gmail.com>
Subject: watchdog: mtk_wdt: Stop a running watchdog over system sleep even if not opened
This patch modifies the MTK watchdog driver to stop and restart a watchdog
that was left running by the bootloader across system sleep. It also uses
watchdog_stop_ping_on_suspend() to prevent the core's ping worker from
feeding the watchdog during suspend.
Link: https://lore.kernel.org/all/20261011004322.1118027-1-agentzoan@gmail.com/
> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
> index 1630ab65d5932..3c493a470b37a 100644
> --- a/drivers/watchdog/mtk_wdt.c
> +++ b/drivers/watchdog/mtk_wdt.c
> @@ -543,6 +543,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
> mtk_wdt_init(&mtk_wdt->wdt_dev);
>
> watchdog_stop_on_reboot(&mtk_wdt->wdt_dev);
> + watchdog_stop_ping_on_suspend(&mtk_wdt->wdt_dev);
[Severity: High]
Could stopping the ping worker at PM_SUSPEND_PREPARE cause a premature
system reset during process freezing?
By opting in with watchdog_stop_ping_on_suspend(), the core's PM notifier
handles PM_SUSPEND_PREPARE by completely canceling the background ping worker:
drivers/watchdog/watchdog_dev.c:watchdog_dev_suspend() {
...
if (test_bit(WDOG_NO_PING_ON_SUSPEND, &wdd->status)) {
...
kthread_cancel_work_sync(&wd_data->work);
}
}
Immediately following the PM_SUSPEND_PREPARE notifiers, the suspend core
freezes user-space processes:
kernel/power/suspend.c:suspend_prepare() {
...
error = suspend_freeze_processes();
}
Because freezing tasks and syncing filesystems can routinely block for
several seconds, if the hardware watchdog is initialized with a short
timeout (e.g., 2 seconds via a module parameter), could the hardware
timer expire and hard-reset the board before the device's actual suspend
callback (mtk_wdt_suspend) is ever reached?
Prior to this patch, the unfreezable watchdog_kworker would continue to
feed the hardware during this variable freezing delay.
> err = devm_watchdog_register_device(dev, &mtk_wdt->wdt_dev);
> if (unlikely(err))
> return err;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261011011536.1139162-1-agentzoan@gmail.com?part=1
prev parent reply other threads:[~2026-10-11 1:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-11 1:15 [PATCH v2] watchdog: mtk_wdt: Stop a running watchdog over system sleep even if not opened zoan37
2026-10-11 1:29 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-166960@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agentzoan@gmail.com \
--cc=linux-watchdog@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox