From: sashiko-bot@kernel.org
To: kr494167@gmail.com
Cc: linux-watchdog@vger.kernel.org
Subject: Re: [PATCH] watchdog: atcwdt200: fix return value when watchdog is enabled
Date: Wed, 22 Jul 2026 16:46:37 +0000 [thread overview]
Message-ID: <20260722164637.8EACF1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260722163706.14238-1-kr494167@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [Low] Setting `drv_data->int_timer_type` is useless dead code because the function immediately returns a fatal error.
- [Low] Kernel-doc comment for `atcwdt_get_int_timer_type()` contradicts the new code.
Pre-existing issues:
- [High] Failing driver probe when the hardware watchdog is already running orphans the timer and guarantees an unhandled system reset.
- [High] The watchdog restart handler acquires a standard spinlock in atomic context, causing a lockdep splat and sleep-in-atomic bug on PREEMPT_RT.
--
--- Patch [1]: [PATCH] watchdog: atcwdt200: fix return value when watchdog is enabled ---
commit 8139a405984f14ed6f8cead4736a58db3d02c322
Author: Surendra Singh Chouhan <kr494167@gmail.com>
watchdog: atcwdt200: fix return value when watchdog is enabled
This commit modifies atcwdt_get_int_timer_type() to return -EBUSY via
dev_err_probe() when the watchdog is already enabled, fixing an issue
where probe() incorrectly returned a positive value on failure.
> diff --git a/drivers/watchdog/atcwdt200_wdt.c b/drivers/watchdog/atcwdt200_wdt.c
> --- a/drivers/watchdog/atcwdt200_wdt.c
> +++ b/drivers/watchdog/atcwdt200_wdt.c
> @@ -274,7 +274,9 @@ static int atcwdt_get_int_timer_type(struct atcwdt_drv *drv_data)
> regmap_read(drv_data->regmap, REG_CTRL, &val);
> if (val & CTRL_WDT_EN) {
> spin_unlock(&drv_data->lock);
> - return TMR_UNKNOWN;
> + drv_data->int_timer_type = TMR_UNKNOWN;
[Severity: Low]
Is there a need to set drv_data->int_timer_type here? Since the function
immediately returns a fatal error, the driver probe will fail and free the
structure. This appears to be dead code.
> + return dev_err_probe(dev, -EBUSY,
> + "Watchdog is enabled, cannot detect timer type\n");
[Severity: High]
This is a pre-existing issue, but does failing the driver probe when the
hardware watchdog is running orphan the timer?
If a bootloader leaves the watchdog enabled, refusing to bind the driver here
guarantees an unhandled system reset. Should the driver adopt the running
watchdog instead and set WDOG_HW_RUNNING?
> }
>
> /*
[Severity: Low]
The kernel-doc comment for atcwdt_get_int_timer_type() currently states:
* Note: This function must only be called when the ATCWDT200 watchdog is
* disabled. If the watchdog is enabled, this function returns TMR_UNKNOWN.
Since this patch changes the return value to -EBUSY, should the documentation
be updated to match the new behavior?
[Severity: High]
This is a pre-existing issue, but can the lock used in atcwdt_restart() cause
a sleep-in-atomic bug on PREEMPT_RT kernels?
The watchdog restart handler acquires a standard spinlock:
drivers/watchdog/atcwdt200_wdt.c:atcwdt_restart() {
...
spin_lock(&drv_data->lock);
...
}
Since restart handlers are invoked in atomic context with local interrupts
and preemption disabled, acquiring a standard spinlock_t blocks and can sleep
on PREEMPT_RT. Should this lock be converted to a raw_spinlock_t?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260722163706.14238-1-kr494167@gmail.com?part=1
next prev parent reply other threads:[~2026-07-22 16:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 16:37 [PATCH] watchdog: atcwdt200: fix return value when watchdog is enabled kr494167
2026-07-22 16:46 ` sashiko-bot [this message]
2026-07-22 17:20 ` Guenter Roeck
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=20260722164637.8EACF1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kr494167@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