All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] watchdog: mtk_wdt: Stop a running watchdog over system sleep even if not opened
@ 2026-10-11  1:15 zoan37
  2026-10-11  1:29 ` sashiko-bot
  0 siblings, 1 reply; 2+ messages in thread
From: zoan37 @ 2026-10-11  1:15 UTC (permalink / raw)
  To: Wim Van Sebroeck, Guenter Roeck
  Cc: Matthias Brugger, AngeloGioacchino Del Regno, Freddy Hsin,
	linux-watchdog, linux-mediatek, linux-arm-kernel, linux-kernel

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



^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH v2] watchdog: mtk_wdt: Stop a running watchdog over system sleep even if not opened
  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
  0 siblings, 0 replies; 2+ messages in thread
From: sashiko-bot @ 2026-10-11  1:29 UTC (permalink / raw)
  To: zoan37; +Cc: linux-watchdog

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-10-11  1:29 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.