From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Sebastian Reichel <sebastian.reichel@collabora.com>,
Guenter Roeck <linux@roeck-us.net>,
Wim Van Sebroeck <wim@linux-watchdog.org>,
Sasha Levin <sashal@kernel.org>,
linux-watchdog@vger.kernel.org
Subject: [PATCH AUTOSEL 6.16-5.4] watchdog: dw_wdt: Fix default timeout
Date: Tue, 5 Aug 2025 09:09:09 -0400 [thread overview]
Message-ID: <20250805130945.471732-34-sashal@kernel.org> (raw)
In-Reply-To: <20250805130945.471732-1-sashal@kernel.org>
From: Sebastian Reichel <sebastian.reichel@collabora.com>
[ Upstream commit ac3dbb91e0167d017f44701dd51c1efe30d0c256 ]
The Synopsys Watchdog driver sets the default timeout to 30 seconds,
but on some devices this is not a valid timeout. E.g. on RK3588 the
actual timeout being used is 44 seconds instead.
Once the watchdog is started the value is updated accordingly, but
it would be better to expose a sensible timeout to userspace without
the need to first start the watchdog.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20250717-dw-wdt-fix-initial-timeout-v1-1-86dc864d48dd@kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Based on my analysis of the commit, here's my assessment:
**Backport Status: YES**
## Extensive Explanation:
This commit is a clear bugfix that should be backported to stable kernel
trees for the following reasons:
### 1. **It fixes a real user-visible bug**
The commit addresses a problem where the watchdog driver exposes an
incorrect timeout value (30 seconds) to userspace when that value is not
actually valid for the hardware. On RK3588 specifically, the hardware
uses 44 seconds instead of the requested 30 seconds, creating a
discrepancy between what userspace sees and what the hardware actually
does.
### 2. **The fix is minimal and contained**
The change adds only two lines of code:
```c
+ /* Limit timeout value to hardware constraints. */
+ dw_wdt_set_timeout(wdd, wdd->timeout);
```
This simply calls the existing `dw_wdt_set_timeout()` function during
initialization to ensure the timeout value is properly validated and
adjusted to hardware constraints before the watchdog is registered with
the kernel.
### 3. **No architectural changes or new features**
The commit doesn't introduce any new functionality or change the
driver's architecture. It merely ensures that the existing timeout
validation logic (which was already being called when the watchdog
starts) is also applied during initialization.
### 4. **Low risk of regression**
The `dw_wdt_set_timeout()` function is already being called in other
code paths (when the watchdog is started, when timeout is changed). This
commit just ensures it's also called during probe to validate the
initial timeout. The function itself uses `dw_wdt_find_best_top()` to
find a valid hardware timeout value that's closest to the requested
value.
### 5. **Affects user-facing behavior**
Without this fix, userspace applications that query the watchdog timeout
before starting it will get an incorrect value (30 seconds) that doesn't
match what the hardware will actually use (e.g., 44 seconds on RK3588).
This could lead to incorrect assumptions about watchdog behavior in
monitoring and recovery systems.
### 6. **The fix follows established patterns**
The commit message notes "it would be better to expose a sensible
timeout to userspace without the need to first start the watchdog" -
this is a reasonable expectation that userspace should have accurate
information about hardware settings without needing to activate the
hardware first.
### 7. **Subsystem maintainer review**
The commit has been reviewed by Guenter Roeck (the watchdog subsystem
maintainer) and signed off by both subsystem maintainers, indicating
it's a proper fix that they consider important.
The fix ensures that the watchdog timeout value exposed to userspace
through sysfs and ioctl interfaces accurately reflects the hardware's
actual timeout capability from the moment the driver is loaded, rather
than showing an incorrect default value until the watchdog is started.
This is particularly important for systems that need to make decisions
based on watchdog capabilities before actually starting the watchdog
timer.
drivers/watchdog/dw_wdt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
index 26efca9ae0e7..c3fbb6068c52 100644
--- a/drivers/watchdog/dw_wdt.c
+++ b/drivers/watchdog/dw_wdt.c
@@ -644,6 +644,8 @@ static int dw_wdt_drv_probe(struct platform_device *pdev)
} else {
wdd->timeout = DW_WDT_DEFAULT_SECONDS;
watchdog_init_timeout(wdd, 0, dev);
+ /* Limit timeout value to hardware constraints. */
+ dw_wdt_set_timeout(wdd, wdd->timeout);
}
platform_set_drvdata(pdev, dw_wdt);
--
2.39.5
prev parent reply other threads:[~2025-08-05 13:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250805130945.471732-1-sashal@kernel.org>
2025-08-05 13:08 ` [PATCH AUTOSEL 6.16-5.15] watchdog: sbsa: Adjust keepalive timeout to avoid MediaTek WS0 race condition Sasha Levin
2025-08-05 13:09 ` [PATCH AUTOSEL 6.16-5.15] watchdog: iTCO_wdt: Report error if timeout configuration fails Sasha Levin
2025-08-05 13:09 ` Sasha Levin [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=20250805130945.471732-34-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=patches@lists.linux.dev \
--cc=sebastian.reichel@collabora.com \
--cc=stable@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).