From: sashiko-bot@kernel.org
To: "Tomer Maimon" <tmaimon77@gmail.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org,
linux-watchdog@vger.kernel.org
Subject: Re: [PATCH v2 2/3] docs: watchdog: npcm: Add reset status description
Date: Mon, 22 Jun 2026 08:34:45 +0000 [thread overview]
Message-ID: <20260622083445.C33041F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260622083046.3189603-3-tmaimon77@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] UAPI Semantic Violation: Overloading generic watchdog bootstatus flags with unrelated platform-specific reset causes.
--
commit 622b044102abac9e6e33a21b4739ad90ba16eec5
Author: Tomer Maimon <tmaimon77@gmail.com>
docs: watchdog: npcm: Add reset status description
This commit adds documentation describing how the NPCM watchdog driver
reports reset causes through bootstatus on NPCM750 and NPCM845 systems. It
documents the fixed reset flag mapping, watchdog instance mapping, and
sysfs reporting behavior.
> diff --git a/Documentation/watchdog/npcm_wdt.rst b/Documentation/watchdog/npcm_wdt.rst
> new file mode 100644
> index 0000000000000..48f0c7920c112
> --- /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 intentional to overload standard watchdog UAPI flags with unrelated
platform-specific reset causes?
Mapping "power-on reset" (NPCM_PORST) to WDIOF_OVERHEAT ("Reset due to CPU
overheat") and "core reset" (NPCM_CORST) to WDIOF_FANFAULT ("Fan failed") will
cause generic userspace applications, system managers, and monitoring tools to
misinterpret the values. This could lead to false reports of CPU overheating
or fan failures during normal cold boots.
Should these hardware-specific reset reasons be exposed via a dedicated
reset-reason framework or custom sysfs attributes instead of redefining
standardized generic UAPI flags?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260622083046.3189603-1-tmaimon77@gmail.com?part=2
next prev parent reply other threads:[~2026-06-22 8:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-22 8:30 [PATCH v2 0/3] watchdog: npcm: Add reset status detection support Tomer Maimon
2026-06-22 8:30 ` [PATCH v2 1/3] dt-bindings: watchdog: npcm: add GCR syscon property Tomer Maimon
2026-06-22 8:30 ` [PATCH v2 2/3] docs: watchdog: npcm: Add reset status description Tomer Maimon
2026-06-22 8:34 ` sashiko-bot [this message]
2026-06-22 8:30 ` [PATCH v2 3/3] watchdog: npcm: add bootstatus support Tomer Maimon
2026-06-22 8:42 ` sashiko-bot
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=20260622083445.C33041F000E9@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox