All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Tomer Maimon" <tmaimon77@gmail.com>
Cc: robh@kernel.org, devicetree@vger.kernel.org,
	linux-watchdog@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v3 2/3] docs: watchdog: npcm: Add reset status description
Date: Sun, 05 Jul 2026 14:06:17 +0000	[thread overview]
Message-ID: <20260705140617.A71F11F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260705140100.1543486-3-tmaimon77@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The watchdog driver abuses standard Watchdog UAPI constants to report non-watchdog platform reset causes, violating the userspace ABI contract.
--

commit 72fd6c8b87d96376853f3dcd5ef1597495cf9817
Author: Tomer Maimon <tmaimon77@gmail.com>

docs: watchdog: npcm: Add reset status description

Add documentation describing how the NPCM watchdog driver reports reset
causes through bootstatus on NPCM750 and NPCM845 systems.

> diff --git a/Documentation/watchdog/npcm_wdt.rst b/Documentation/watchdog/npcm_wdt.rst
> new file mode 100644
> index 0000000000000..cdc45ade9e0d9
> --- /dev/null
> +++ b/Documentation/watchdog/npcm_wdt.rst

[ ... ]

> +.. list-table:: Reset-cause mapping
> +   :header-rows: 1
> +
> +   * - Platform
> +     - Reset indication
> +     - Bootstatus flag
> +     - Reported meaning
> +   * - NPCM750 and NPCM845
> +     - ``PORST``
> +     - ``WDIOF_OVERHEAT``
> +     - power-on reset
> +   * - NPCM750 and NPCM845
> +     - ``CORST``
> +     - ``WDIOF_FANFAULT``
> +     - core reset

[Severity: High]
Is it correct to map generic Watchdog UAPI thermal and fan failure flags to
standard platform reset indications?

The generic Watchdog API defines strict semantics for its status flags.
For instance, WDIOF_OVERHEAT means a reset due to CPU overheat, and
WDIOF_FANFAULT means a fan failed. By mapping standard SoC reset causes like
Power-On Reset (PORST) to WDIOF_OVERHEAT and Core Reset (CORST) to
WDIOF_FANFAULT, might this break the userspace ABI contract?

During a normal cold boot, reading the SoC latch would unconditionally expose
this to userspace via the WDIOC_GETBOOTSTATUS ioctl or sysfs. Standard
userspace monitoring daemons (like systemd or wdctl) reading bootstatus
might erroneously conclude the system suffered a thermal event or fan failure,
potentially triggering unintended emergency actions or false alarms.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260705140100.1543486-1-tmaimon77@gmail.com?part=2

  reply	other threads:[~2026-07-05 14:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-05 14:00 [PATCH v3 0/3] watchdog: npcm: Add reset status detection support Tomer Maimon
2026-07-05 14:00 ` [PATCH v3 1/3] dt-bindings: watchdog: npcm: add GCR syscon property Tomer Maimon
2026-07-05 14:36   ` Conor Dooley
2026-07-05 14:00 ` [PATCH v3 2/3] docs: watchdog: npcm: Add reset status description Tomer Maimon
2026-07-05 14:06   ` sashiko-bot [this message]
2026-07-06  9:44     ` Tomer Maimon
2026-07-05 14:01 ` [PATCH v3 3/3] watchdog: npcm: add bootstatus support Tomer Maimon
2026-07-05 14:10   ` sashiko-bot
2026-07-06 14:47     ` Tomer Maimon

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=20260705140617.A71F11F000E9@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=tmaimon77@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.