Re: [PATCH v4 2/3] docs: watchdog: npcm: Add reset status description

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The documented reset-cause mapping hijacks standard watchdog bootstatus flags for unrelated SoC reset reasons, breaking UAPI semantics.
--

commit f4b3dfdb40f0d729f339392746d12863cb907b7e
Author: Tomer Maimon <[email protected]>

docs: watchdog: npcm: Add reset status description

This commit adds documentation describing how the NPCM watchdog driver
reports reset causes on NPCM750 and NPCM845 systems. It details the fixed
mapping between SoC reset indications and generic watchdog bootstatus flags.

> diff --git a/Documentation/watchdog/npcm_wdt.rst b/Documentation/watchdog/npcm_wdt.rst
> new file mode 100644
> --- /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]
Does this mapping redefine standard watchdog bootstatus flags for unrelated
SoC reset reasons?

Standard watchdog UAPI definitions expect WDIOF_OVERHEAT to specifically
mean a reset due to a CPU overheat condition, and WDIOF_FANFAULT to mean a
fan failure. 

Mapping standard power-on resets (PORST) or core resets (CORST) to these
flags will cause userspace tools and daemons querying WDIOC_GETBOOTSTATUS
to erroneously report critical hardware failures during normal boot operations
or software resets.

Is there a way to expose these SoC-specific reset reasons to userspace
without conflicting with established UAPI semantics?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2