From: zoan37 <agentzoan@gmail.com>
To: Wim Van Sebroeck <wim@linux-watchdog.org>,
Guenter Roeck <linux@roeck-us.net>
Cc: Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Freddy Hsin <freddy.hsin@mediatek.com>,
linux-watchdog@vger.kernel.org,
linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: [PATCH v2] watchdog: mtk_wdt: Stop a running watchdog over system sleep even if not opened
Date: Sat, 10 Oct 2026 21:15:36 -0400 [thread overview]
Message-ID: <20261011011536.1139162-1-agentzoan@gmail.com> (raw)
mtk_wdt_suspend() and mtk_wdt_resume() only stop and restart the
watchdog when it is active, that is, when userspace has opened it.
But a watchdog that the bootloader left enabled stays enabled at probe,
marked WDOG_HW_RUNNING, and the watchdog core pings it until userspace
takes over; that has been the case since
commit bbece05c0d3a ("watchdog: mtk_wdt: Remove mtk_wdt_stop() in probe()
to prevent the system freeze and it doesn't reboot by watchdog problem").
If the system suspends before userspace opens the device, or userspace
never does, nothing stops the watchdog and nothing pings it while the
system sleeps, so it resets the system one timeout (31 s by default)
into the sleep.
Also stop it on suspend and restart it on resume when it is running in
hardware, like sp805_wdt does.
The core's ping worker for such a watchdog would keep running across
the sleep and could ping the stopped watchdog after resume, before
mtk_wdt_resume() has started it again. Have the core stop the worker
over system sleep with watchdog_stop_ping_on_suspend(), as imx2_wdt
does: it pings one last time before the system suspends and restarts
the worker once everything has resumed.
Fixes: bbece05c0d3a ("watchdog: mtk_wdt: Remove mtk_wdt_stop() in probe() to prevent the system freeze and it doesn't reboot by watchdog problem")
Assisted-by: LLM
Signed-off-by: zoan37 <agentzoan@gmail.com>
---
Changes in v2:
- Also call watchdog_stop_ping_on_suspend() in probe, so the core's ping
worker doesn't run across the sleep and ping the stopped watchdog
before mtk_wdt_resume() (pointed out by the Sashiko review of v1).
- Link to v1: https://lore.kernel.org/all/20261011004322.1118027-1-agentzoan@gmail.com/
Testing: on an MT8189 Chromebook (next-20261008 plus MT8189 support)
whose firmware leaves the watchdog off; a local module parameter
(mtk_wdt.start_timeout=31) starts it in probe the same way a
bootloader-enabled watchdog is picked up (WDOG_HW_RUNNING set, fed by
the watchdog core, nobody opening /dev/watchdog). Without the suspend
change the board reset about 30 s into s2idle. With v2: 4 s2idle cycles
of 60 s each, awake 45 s after every resume, all came back with no
reset (so the worker feeds it again after resume). v1 also passed a
10-minute s2idle sleep. Not tested with a watchdog actually left enabled
by a bootloader. Built with W=1, checkpatch --strict clean apart from
the sign-off.
drivers/watchdog/mtk_wdt.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 1630ab65d593..3c493a470b37 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);
err = devm_watchdog_register_device(dev, &mtk_wdt->wdt_dev);
if (unlikely(err))
return err;
@@ -572,7 +573,8 @@ static int mtk_wdt_suspend(struct device *dev)
{
struct mtk_wdt_dev *mtk_wdt = dev_get_drvdata(dev);
- if (watchdog_active(&mtk_wdt->wdt_dev))
+ if (watchdog_active(&mtk_wdt->wdt_dev) ||
+ watchdog_hw_running(&mtk_wdt->wdt_dev))
mtk_wdt_stop(&mtk_wdt->wdt_dev);
return 0;
@@ -582,7 +584,8 @@ static int mtk_wdt_resume(struct device *dev)
{
struct mtk_wdt_dev *mtk_wdt = dev_get_drvdata(dev);
- if (watchdog_active(&mtk_wdt->wdt_dev)) {
+ if (watchdog_active(&mtk_wdt->wdt_dev) ||
+ watchdog_hw_running(&mtk_wdt->wdt_dev)) {
mtk_wdt_start(&mtk_wdt->wdt_dev);
mtk_wdt_ping(&mtk_wdt->wdt_dev);
}
base-commit: aac26bee2287c88af5be5a5ff96d783b19a28790
--
2.43.0
reply other threads:[~2026-10-11 1:15 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20261011011536.1139162-1-agentzoan@gmail.com \
--to=agentzoan@gmail.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=freddy.hsin@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=matthias.bgg@gmail.com \
--cc=wim@linux-watchdog.org \
/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
all inboxes | Powered by JetHome®