Re: [PATCH 0/5] watchdog: rzn1: Add support for direct hardware reset

[Herve Codina]

Hi Wolfram, Geert, Krzysztof

On Tue, 10 Mar 2026 22:53:01 +0100
Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx> wrote:

> Hi Herve,
> 
> > On timeout, the watchdog also asserts its dedicated reset line. This
> > reset line is connected to the reset controller (part of sysctrl) and,
> > if this line is enabled as a possible reset source at the reset
> > controller level, it initiates a system reset.  
> 
> Okay, this seems similar to R-Car SoCs, so multiple things to add from
> my side:
> 
> * I agree with Krzysztof that the renesas-vendor-binding is not the way
>   to go. The information could be either deduced from the register range
>   or you could have a link to the syscon describing somehow which reset
>   to allow.

I think deducing the information from the register range could be ok without
the need for introducing and use syscon.

On think that could be missing is the way to know if we are allowed or not
to enable this reset source.

Maybe a new "renesas,reset-type" property in the watchdog node could give
this information. This property could take the following value:
   - "soft":
     On timeout, the watchdog triggers an interrupt.

   - "hard":
     On timeout, the watchdog asserts the directly the system reset.

But I am not sure that this king of property will be accepted by Krzysztof
even if similar properties for similar features exist in other watchdog
bindings.

> 
> But:
> 
> * On R-Car, we require the firmware to correctly setup which resets are
>   allowed. Only in cases of broken firmware, we override it in the
>   system controller driver. The latter could probably be argued here.
>   The firmware is old and will probably be not updated anymore.
> 
> * If the watchdog driver kind of unconditionally allows its own reset,
>   we could keep it very simple and just unconditionally allow watchdog
>   resets when probing the sysctrl driver?
> 
> * If you don't like this, you could also parse the DT for enabled
>   watchdogs when probing the sysctrl driver and act upon findings?
> 

Looked deeper in the code.
On RZ/N1, the watchdog interrupt handler calls emergency_restart().

The clock driver (driver handling the sysctrl register area) allows the
software reset source unconditionally and register an handler to request
this software reset on system restart notification [1] and [2].

Whatever resets allowed by the firmware, it is already overridden for the
sofware reset and the watchdog resets the system.

So my plan for the next iteration is, as you suggested, unconditionally
allows watchdog resets in the clock driver probe(). Indeed it is the
driver in charge of sysctrl.

Geert any opinion on this topic?

[1] https://elixir.bootlin.com/linux/v7.0-rc1/source/drivers/clk/renesas/r9a06g032-clocks.c#L1346
[2] https://elixir.bootlin.com/linux/v7.0-rc1/source/drivers/clk/renesas/r9a06g032-clocks.c#L1282

Best regards,
Hervé