<div dir="ltr"><div dir="ltr">Hi Krzysztof,<div><br></div><div>Thanks for your comments.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, 16 Feb 2026 at 13:16, Krzysztof Kozlowski <<a href="mailto:krzk@kernel.org">krzk@kernel.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 16/02/2026 12:10, Tomer Maimon wrote:<br>
> Hi Krzysztof,<br>
> <br>
> Thanks for your review.<br>
> <br>
> On Tue, 10 Feb 2026 at 18:11, Krzysztof Kozlowski <<a href="mailto:krzk@kernel.org" target="_blank">krzk@kernel.org</a>> wrote:<br>
> <br>
>> On 10/02/2026 14:38, Tomer Maimon wrote:<br>
>>> Add reset status detection for NPCM7XX and NPCM8XX platforms via syscon<br>
>>> integration. Document syscon property and three configurable reset type<br>
>>> properties (nuvoton,card-reset-type, nuvoton,ext1-reset-type,<br>
>>> nuvoton,ext2-reset-type)that map reset signal detection to specific<br>
>>> reset bit positions.<br>
>>><br>
>>> Signed-off-by: Tomer Maimon <<a href="mailto:tmaimon77@gmail.com" target="_blank">tmaimon77@gmail.com</a>><br>
>>> ---<br>
>>>  .../watchdog/nuvoton,npcm750-wdt.yaml         | 51 ++++++++++++++++++-<br>
>>>  1 file changed, 49 insertions(+), 2 deletions(-)<br>
>>><br>
>>> diff --git<br>
>> a/Documentation/devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml<br>
>> b/Documentation/devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml<br>
>>> index 7aa30f5b5c49..054cc0115af2 100644<br>
>>> --- a/Documentation/devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml<br>
>>> +++ b/Documentation/devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml<br>
>>> @@ -12,7 +12,7 @@ maintainers:<br>
>>>  description:<br>
>>>    Nuvoton NPCM timer module provides five 24-bit timer counters, and a<br>
>> watchdog.<br>
>>>    The watchdog supports a pre-timeout interrupt that fires 10ms before<br>
>> the<br>
>>> -  expiry.<br>
>>> +  expiry and reset status detection via syscon integration.<br>
>>><br>
>>>  allOf:<br>
>>>    - $ref: watchdog.yaml#<br>
>>> @@ -40,12 +40,55 @@ properties:<br>
>>>    clock-frequency:<br>
>>>      description: Frequency in Hz of the clock that drives the NPCM<br>
>> timer.<br>
>>><br>
>>> +  syscon:<br>
>><br>
>> First iteration. See "How to Get Your DT Schema Bindings Accepted in<br>
>> Less Than 10 Iterations"<br>
>><br>
> Thanks, it was very helpful.<br>
> the syscon property is already found in the WD node<br>
> in nuvoton-common-npcm8xx.dtsi file, what should I do:<br>
<br>
How is that file related to this binding?<br>
<br>
Either you document existing ABI or you add new (for new device). Commit<br>
msg MUST be explicit about it and provide the reasons. If wrong (e.g.<br>
discouraged) ABI was already used then it depends how and when it got<br>
into the kernel, e.g. if someone bypassed DT completely just to get it<br>
inside.<br></blockquote><div><font face="arial, sans-serif"><span style="font-size:14px">The </span><code style="font-size:14px">syscon</code><span style="font-size:14px"> 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 (</span><code style="font-size:14px">nuvoton,sysgcr</code><span style="font-size:14px">) as the preferred one, and explain this clearly in the commit message.</span></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> 1. Modify the syson to nuvoton,sys-gcr like in the dtsi?<br>
> 2. Still use the syscon property in the dtsi file, therefore stick with the<br>
> syscon add.<br>
> <br>
<br>
>><br>
>> or just read the docs please.<br>
>><br>
>>> +    description: phandle to the Global Control Register (GCR) syscon<br>
>> node.<br>
>>> +    $ref: /schemas/types.yaml#/definitions/phandle<br>
>>> +<br>
>>> +  nuvoton,card-reset-type:<br>
>>> +    description: Reset type for external card reset signal detection.<br>
>>> +    enum:<br>
>>> +      - porst<br>
>>> +      - corst<br>
>>> +      - wd0<br>
>>> +      - wd1<br>
>>> +      - wd2<br>
>>> +      - sw1<br>
>>> +      - sw2<br>
>>> +      - sw3<br>
>>> +      - sw4<br>
>><br>
>> You want it to be static configuration, so cannot be changed runtime? Why?<br>
>><br>
> Yes, it is only an indication of the most recent reset in the BMC. In<br>
> addition:<br>
> 1. The driver reads the reset register during the probe. After this read,<br>
> the reset register should be cleared so it’s ready for the next system<br>
> reset.<br>
> 2. I’m not aware of any service function that allows changing the reset<br>
> indication at runtime.<br>
<br>
Huh? If the driver reads the reset you do not need this property at all.<br></blockquote><div><font face="arial, sans-serif"><span style="font-size:14px">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.</span> </font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Best regards,<br>
Krzysztof<br></blockquote><div><br></div><div>Best regards,</div><div><br></div><div>Tomer </div></div></div>