[PATCH v1 1/2] dt-bindings: watchdog: Add NPCM reset status support

[Tomer Maimon]

Hi Krzysztof,

Thanks for your comments.

On Mon, 16 Feb 2026 at 13:16, Krzysztof Kozlowski <krzk at kernel.org> wrote:

> On 16/02/2026 12:10, Tomer Maimon wrote:
> > Hi Krzysztof,
> >
> > Thanks for your review.
> >
> > On Tue, 10 Feb 2026 at 18:11, Krzysztof Kozlowski <krzk at kernel.org>
> wrote:
> >
> >> On 10/02/2026 14:38, Tomer Maimon wrote:
> >>> Add reset status detection for NPCM7XX and NPCM8XX platforms via syscon
> >>> integration. Document syscon property and three configurable reset type
> >>> properties (nuvoton,card-reset-type, nuvoton,ext1-reset-type,
> >>> nuvoton,ext2-reset-type)that map reset signal detection to specific
> >>> reset bit positions.
> >>>
> >>> Signed-off-by: Tomer Maimon <tmaimon77 at gmail.com>
> >>> ---
> >>>  .../watchdog/nuvoton,npcm750-wdt.yaml         | 51 ++++++++++++++++++-
> >>>  1 file changed, 49 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git
> >> a/Documentation/devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml
> >> b/Documentation/devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml
> >>> index 7aa30f5b5c49..054cc0115af2 100644
> >>> ---
> a/Documentation/devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml
> >>> +++
> b/Documentation/devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml
> >>> @@ -12,7 +12,7 @@ maintainers:
> >>>  description:
> >>>    Nuvoton NPCM timer module provides five 24-bit timer counters, and a
> >> watchdog.
> >>>    The watchdog supports a pre-timeout interrupt that fires 10ms before
> >> the
> >>> -  expiry.
> >>> +  expiry and reset status detection via syscon integration.
> >>>
> >>>  allOf:
> >>>    - $ref: watchdog.yaml#
> >>> @@ -40,12 +40,55 @@ properties:
> >>>    clock-frequency:
> >>>      description: Frequency in Hz of the clock that drives the NPCM
> >> timer.
> >>>
> >>> +  syscon:
> >>
> >> First iteration. See "How to Get Your DT Schema Bindings Accepted in
> >> Less Than 10 Iterations"
> >>
> > Thanks, it was very helpful.
> > the syscon property is already found in the WD node
> > in nuvoton-common-npcm8xx.dtsi file, what should I do:
>
> How is that file related to this binding?
>
> Either you document existing ABI or you add new (for new device). Commit
> msg MUST be explicit about it and provide the reasons. If wrong (e.g.
> discouraged) ABI was already used then it depends how and when it got
> into the kernel, e.g. if someone bypassed DT completely just to get it
> inside.
>
The syscon property is already used in the upstream NPCM8xx DTSI watchdog
node, so I will document it as existing ABI and mark it deprecated. I will
add a new vendor‑specific property (nuvoton,sysgcr) as the preferred one,
and explain this clearly in the commit message.

>
> > 1. Modify the syson to nuvoton,sys-gcr like in the dtsi?
> > 2. Still use the syscon property in the dtsi file, therefore stick with
> the
> > syscon add.
> >
>
> >>
> >> or just read the docs please.
> >>
> >>> +    description: phandle to the Global Control Register (GCR) syscon
> >> node.
> >>> +    $ref: /schemas/types.yaml#/definitions/phandle
> >>> +
> >>> +  nuvoton,card-reset-type:
> >>> +    description: Reset type for external card reset signal detection.
> >>> +    enum:
> >>> +      - porst
> >>> +      - corst
> >>> +      - wd0
> >>> +      - wd1
> >>> +      - wd2
> >>> +      - sw1
> >>> +      - sw2
> >>> +      - sw3
> >>> +      - sw4
> >>
> >> You want it to be static configuration, so cannot be changed runtime?
> Why?
> >>
> > Yes, it is only an indication of the most recent reset in the BMC. In
> > addition:
> > 1. The driver reads the reset register during the probe. After this read,
> > the reset register should be cleared so it’s ready for the next system
> > reset.
> > 2. I’m not aware of any service function that allows changing the reset
> > indication at runtime.
>
> Huh? If the driver reads the reset you do not need this property at all.
>
I understand that since the driver can read the reset cause directly from
the GCR, no DT properties should be used for this. I’ll drop the reset‑type
properties and handle the mapping in the driver based on the SoC.

>
> Best regards,
> Krzysztof
>

Best regards,

Tomer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20260216/5bba7d96/attachment.htm>