From: sashiko-bot@kernel.org
To: Prabhakar <prabhakar.csengg@gmail.com>
Cc: linux-watchdog@vger.kernel.org, wsa+renesas@sang-engineering.com
Subject: Re: [PATCH v3 2/3] watchdog: rzv2h: Convert WDTDCR handling to regmap
Date: Fri, 14 Aug 2026 19:26:22 +0000 [thread overview]
Message-ID: <20260814192623.2A9251F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260814191415.2110732-3-prabhakar.mahadev-lad.rj@bp.renesas.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [High] Using a regmap configured with `use_raw_spinlock = true` in the watchdog restart handler introduces a deadlock if a panic occurs while another CPU holds the regmap lock.
- [High] The watchdog restart handler inappropriately aborts on regmap errors, silently preventing system reboot.
Pre-existing issues:
- [High] Calling `clk_enable()` from `rzv2h_wdt_restart()` can cause deadlocks if another CPU holds the corresponding framework spinlocks during a panic.
--
--- Patch [2]: [PATCH v3 2/3] watchdog: rzv2h: Convert WDTDCR handling to regmap ---
commit 81d528488e87b317129eaa95c0076e2e770f3265
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: watchdog: rzv2h: Convert WDTDCR handling to regmap
This commit converts the WDTDCR register access from raw readl/writel
variants over to the regmap framework using devm_regmap_init_mmio(). This
refactoring allows the driver to subsequently support syscon-based system
controllers natively.
> diff --git a/drivers/watchdog/rzv2h_wdt.c b/drivers/watchdog/rzv2h_wdt.c
> index b770226f785ea..cf28caef31e8e 100644
> --- a/drivers/watchdog/rzv2h_wdt.c
> +++ b/drivers/watchdog/rzv2h_wdt.c
[ ... ]
> @@ -91,20 +92,12 @@ static int rzv2h_wdt_ping(struct watchdog_device *wdev)
>
> static int rzt2h_wdt_wdtdcr_count_stop(struct rzv2h_wdt_priv *priv)
> {
> - u32 reg = readl(priv->wdtdcr + WDTDCR);
> -
> - writel(reg | WDTDCR_WDTSTOPCTRL, priv->wdtdcr + WDTDCR);
> -
> - return 0;
> + return regmap_set_bits(priv->wdtdcr_regmap, WDTDCR, WDTDCR_WDTSTOPCTRL);
> }
>
> static int rzt2h_wdt_wdtdcr_count_start(struct rzv2h_wdt_priv *priv)
> {
> - u32 reg = readl(priv->wdtdcr + WDTDCR);
> -
> - writel(reg & ~WDTDCR_WDTSTOPCTRL, priv->wdtdcr + WDTDCR);
> -
> - return 0;
> + return regmap_clear_bits(priv->wdtdcr_regmap, WDTDCR, WDTDCR_WDTSTOPCTRL);
> }
[Severity: High]
Since rzt2h_wdt_wdtdcr_count_start() is called by rzv2h_wdt_restart() during
a system panic, returning regmap_clear_bits() here means the restart handler
can now fail if the regmap access fails.
If rzt2h_wdt_wdtdcr_count_start() returns an error, the restart handler aborts
early:
rzv2h_wdt_restart()
if (priv->of_data->wdtdcr) {
ret = rzt2h_wdt_wdtdcr_count_start(priv);
if (ret) {
...
return ret;
}
}
rzv2h_wdt_ping(wdev);
Does this silently prevent the watchdog ping and hang the system indefinitely
during a panic instead of rebooting? Should the restart handler ignore the
error to ensure the watchdog ping always occurs?
[Severity: High]
This is a pre-existing issue, but I noticed the restart handler calls
clk_enable() when the watchdog is not active:
rzv2h_wdt_restart()
if (!active) {
ret = clk_enable(priv->pclk);
if (ret)
return ret;
}
Since rzv2h_wdt_restart() is called in an atomic panic context where other CPUs
are halted via smp_send_stop(), can this cause a deadlock? If another CPU is
halted while holding the clock framework's global enable_lock spinlock, the
panicking CPU will spin indefinitely waiting for it.
[ ... ]
> @@ -280,14 +273,30 @@ static const struct watchdog_ops rzv2h_wdt_ops = {
> .restart = rzv2h_wdt_restart,
> };
>
> +static const struct regmap_config rzv2h_wdtdcr_regmap_config = {
> + .name = "wdtdcr",
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .max_register = WDTDCR,
> + .fast_io = true,
> + .use_raw_spinlock = true,
> +};
[Severity: High]
Since rzt2h_wdt_wdtdcr_count_start() uses regmap_clear_bits() and is called
by the panic restart handler, can this raw spinlock introduce a deadlock?
If a panic occurs while another CPU is executing rzv2h_wdt_start() or
rzv2h_wdt_stop() and holds this regmap's raw spinlock, the other CPU is
halted by smp_send_stop(). When the panicking CPU executes rzv2h_wdt_restart(),
it will attempt to acquire the exact same raw spinlock and hang forever
instead of rebooting.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260814191415.2110732-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=2
next prev parent reply other threads:[~2026-08-14 19:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 19:14 [PATCH v3 0/3] watchdog: rzv2h: Convert WDTDCR handling to regmap Prabhakar
2026-08-14 19:14 ` [PATCH v3 1/3] watchdog: rzv2h_wdt: Propagate WDTDCR access errors Prabhakar
2026-08-14 19:26 ` sashiko-bot
2026-08-14 19:14 ` [PATCH v3 2/3] watchdog: rzv2h: Convert WDTDCR handling to regmap Prabhakar
2026-08-14 19:26 ` sashiko-bot [this message]
2026-08-14 19:14 ` [PATCH v3 3/3] watchdog: rzv2h: Drop WDTRCR_RSTIRQS define Prabhakar
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=20260814192623.2A9251F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=prabhakar.csengg@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=wsa+renesas@sang-engineering.com \
/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 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.