From: sashiko-bot@kernel.org
To: "Zi-Yu Chen" <zychennvt@gmail.com>
Cc: devicetree@vger.kernel.org, linux-watchdog@vger.kernel.org,
robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v2 3/3] arm64: dts: nuvoton: Add WDT node for MA35D1 SoC
Date: Fri, 24 Jul 2026 09:25:15 +0000 [thread overview]
Message-ID: <20260724092516.197D81F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260724091427.1689980-4-zychennvt@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Read-modify-write operations on REG_WDT_CTL do not mask write-1-to-clear (W1C) flags, leading to unintentional clearing of pending interrupts or reset flags.
--
--- Patch [3]: [PATCH v2 3/3] arm64: dts: nuvoton: Add WDT node for MA35D1 SoC ---
commit a67dd4dd104040028c3121676f3993b8ca0f94db
Author: Zi-Yu Chen <zychennvt@gmail.com>
arm64: dts: nuvoton: Add WDT node for MA35D1 SoC
This commit adds the Watchdog Timer (WDT) device node to the Nuvoton
MA35D1 device tree. It defines the register space, interrupt, and clock
for the watchdog controller.
> diff --git a/drivers/watchdog/ma35d1_wdt.c b/drivers/watchdog/ma35d1_wdt.c
> new file mode 100644
> index 0000000000000..e5247e55dfee4
> --- /dev/null
> +++ b/drivers/watchdog/ma35d1_wdt.c
[ ... ]
> +static int ma35d1_wdt_stop(struct watchdog_device *wdt_dev)
> +{
> + struct ma35d1_wdt_dev *ma35d1_wdt = watchdog_get_drvdata(wdt_dev);
> + unsigned int val;
> + int ret;
> +
> + guard(spinlock_irqsave)(&ma35d1_wdt->lock);
> + val = readl_relaxed(ma35d1_wdt->wdt_base + REG_WDT_CTL);
> + val &= ~WDTEN;
> + writel_relaxed(val, ma35d1_wdt->wdt_base + REG_WDT_CTL);
[Severity: High]
Does this read-modify-write clear pending write-1-to-clear (W1C) flags?
If IF, WKF, or RSTF bits are set when this reads REG_WDT_CTL, writing the
value back without masking those bits will unintentionally clear them, which
could result in dropped interrupts or wakeup events.
[ ... ]
> +static int ma35d1_wdt_set_timeout(struct watchdog_device *wdt_dev,
> + unsigned int timeout)
> +{
[ ... ]
> + guard(spinlock_irqsave)(&ma35d1_wdt->lock);
> + val = readl_relaxed(ma35d1_wdt->wdt_base + REG_WDT_CTL);
> + val &= ~TOUTSEL;
> + val |= FIELD_PREP(TOUTSEL, i);
> + writel_relaxed(val, ma35d1_wdt->wdt_base + REG_WDT_CTL);
[Severity: High]
Does this update silently drop pending interrupts?
By performing a read-modify-write without masking out the W1C bits (such as
IF or WKF), any currently pending flags will be written back as 1s and cleared
before they can be processed.
[ ... ]
> +static int ma35d1_wdt_suspend(struct device *dev)
> +{
> + struct ma35d1_wdt_dev *ma35d1_wdt = dev_get_drvdata(dev);
> +
> + if (watchdog_active(&ma35d1_wdt->wdt_dev)) {
> + u32 val;
> + int ret;
> +
> + guard(spinlock_irqsave)(&ma35d1_wdt->lock);
> + val = readl_relaxed(ma35d1_wdt->wdt_base + REG_WDT_CTL);
> +
> + if (device_may_wakeup(dev)) {
> + val &= ~RSTEN;
> + val |= (INTEN | WKEN);
> + } else {
> + val &= ~(WDTEN | RSTEN);
> + }
> + writel_relaxed(val, ma35d1_wdt->wdt_base + REG_WDT_CTL);
[Severity: High]
Could this lose a race with a wakeup event?
Writing back the modified control register without clearing the W1C bits first
will unintentionally acknowledge and drop any wakeup or interrupt events that
occurred just before the read.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260724091427.1689980-1-zychennvt@gmail.com?part=3
prev parent reply other threads:[~2026-07-24 9:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-24 9:14 [PATCH v2 0/3] watchdog: ma35d1: Add support for MA35D1 Watchdog Zi-Yu Chen
2026-07-24 9:14 ` [PATCH v2 1/3] dt-bindings: watchdog: Add MA35D1 Watchdog binding Zi-Yu Chen
2026-07-24 9:14 ` [PATCH v2 2/3] watchdog: Add Nuvoton MA35D1 watchdog driver support Zi-Yu Chen
2026-07-24 9:24 ` sashiko-bot
2026-07-24 9:14 ` [PATCH v2 3/3] arm64: dts: nuvoton: Add WDT node for MA35D1 SoC Zi-Yu Chen
2026-07-24 9:25 ` sashiko-bot [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=20260724092516.197D81F000E9@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=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=zychennvt@gmail.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.