devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: Prabhakar <prabhakar.csengg@gmail.com>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org,
	wsa+renesas@sang-engineering.com, linux-watchdog@vger.kernel.org,
	robh@kernel.org
Subject: Re: [PATCH v5 6/8] watchdog: rzv2h: Add syscon support for WDTDCR
Date: Fri, 11 Sep 2026 11:28:03 +0000	[thread overview]
Message-ID: <20260911112804.39EA91F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260911111731.3404308-7-prabhakar.mahadev-lad.rj@bp.renesas.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Watchdog restart handler may deadlock during system panic because it executes a locked regmap operation on a syscon regmap.
--

commit a3a7e98fdd4da0cb2994accaf697498b31aba4d4
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

watchdog: rzv2h: Add syscon support for WDTDCR

This commit introduces syscon regmap support for the WDTDCR (WDT Debug Control
Register) on RZ/T2H and RZ/N2H SoCs. It retrieves the SYSC regmap using the
"renesas,sysc" property and derives the WDTDCR offset from the watchdog
instance index, while preserving MMIO compatibility when the property is absent.

> diff --git a/drivers/watchdog/rzv2h_wdt.c b/drivers/watchdog/rzv2h_wdt.c
> index 550112446db49..9dee410ab7f31 100644
> --- a/drivers/watchdog/rzv2h_wdt.c
> +++ b/drivers/watchdog/rzv2h_wdt.c

[ ... ]

>  static inline int rzt2h_wdt_wdtdcr_count_start_nolock(struct rzv2h_wdt_priv *priv)
>  {
> -	return regmap_clear_bits(priv->wdtdcr_regmap, WDTDCR, WDTDCR_WDTSTOPCTRL);
> +	struct rzv2h_sysc_wdtdcr *sysc = &priv->sysc;
> +
> +	return regmap_clear_bits(sysc->regmap, sysc->offset, WDTDCR_WDTSTOPCTRL);
>  }

[Severity: High]
Does this introduce a deadlock risk during a system panic?

The watchdog restart handler, rzv2h_wdt_restart(), expects an unlocked
execution path to avoid deadlocks and specifically calls this nolock variant:

	if (priv->of_data->wdtdcr) {
		/*
		 * Best effort, ignore return value and use the unlocked
		 * variant of the function to avoid potential deadlocks.
		 */
		rzt2h_wdt_wdtdcr_count_start_nolock(priv);
	}

Previously, the driver used a dedicated MMIO regmap with
.disable_locking = true. Now that sysc->regmap can be a syscon regmap,
which is shared and uses internal spinlocks, regmap_clear_bits() will attempt
to acquire the syscon lock.

If the system panics while another CPU holds this shared syscon spinlock,
will attempting to acquire it here cause the panic handler to hang instead of
resetting the system?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260911111731.3404308-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=6

  reply	other threads:[~2026-09-11 11:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-11 11:17 [PATCH v5 0/8] Add syscon support for Renesas WDT driver Prabhakar
2026-09-11 11:17 ` [PATCH v5 1/8] watchdog: rzv2h: Drop enabling clocks in the restart handler Prabhakar
2026-09-11 11:32   ` sashiko-bot
2026-09-11 11:36     ` Lad, Prabhakar
2026-09-11 11:17 ` [PATCH v5 2/8] watchdog: rzv2h: Drop WDTRCR_RSTIRQS define Prabhakar
2026-09-11 11:17 ` [PATCH v5 3/8] watchdog: rzv2h: Propagate WDTDCR access errors Prabhakar
2026-09-11 11:26   ` sashiko-bot
2026-09-11 11:30     ` Lad, Prabhakar
2026-09-11 11:17 ` [PATCH v5 4/8] watchdog: rzv2h: Use pm_runtime_put_sync() Prabhakar
2026-09-11 11:27   ` sashiko-bot
2026-09-11 12:11     ` Lad, Prabhakar
2026-09-11 11:17 ` [PATCH v5 5/8] watchdog: rzv2h: Convert WDTDCR handling to regmap Prabhakar
2026-09-11 11:17 ` [PATCH v5 6/8] watchdog: rzv2h: Add syscon support for WDTDCR Prabhakar
2026-09-11 11:28   ` sashiko-bot [this message]
2026-09-11 11:39     ` Lad, Prabhakar
2026-09-11 11:17 ` [PATCH v5 7/8] arm64: dts: renesas: r9a09g077: Use CPG/MSSR syscon for WDTDCR access Prabhakar
2026-09-11 11:32   ` sashiko-bot
2026-09-11 12:08     ` Lad, Prabhakar
2026-09-11 11:17 ` [PATCH v5 8/8] arm64: dts: renesas: r9a09g087: " Prabhakar
2026-09-11 11:33   ` sashiko-bot
2026-09-11 12:09     ` Lad, 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=20260911112804.39EA91F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=prabhakar.csengg@gmail.com \
    --cc=robh@kernel.org \
    --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 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).