[PATCH v1 1/2] dt-bindings: watchdog: Add NPCM reset status support
Tomer Maimon
tmaimon77 at gmail.com
Tue Feb 17 01:59:18 AEDT 2026
On Mon, 16 Feb 2026 at 16:48, Krzysztof Kozlowski <krzk at kernel.org> wrote:
> On 16/02/2026 15:37, Tomer Maimon wrote:
> > 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
>
> And how it is used? I cannot find its usage, so I do not agree on
> documenting it. Property should be removed or at least provide the
> justification/impact of removal, if you need it to stay.
>
> Understood. The syscon phandle is used by the watchdog driver to read and
clear the GCR reset‑status registers and then report the reset cause
through the watchdog bootstatus bits.
Therefore, this property should appear in the binding only because the
watchdog driver actually uses it — which I am implementing in this patch
set.
I will document it accordingly, and also add the new nuvoton,sysgcr phandle
as the preferred name.
> 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.
>
>
> Best regards,
> Krzysztof
>
Best regards,
Tomer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20260216/006f798f/attachment.htm>
More information about the openbmc
mailing list