Hi,

The current watchdog driver handling wachdogs of the RZ/N1 SoCs is based
on interrupt only to perform the reset. On the watchdog timeout, an
interrupt is triggered and the software initiates the reset.

The watchdogs available in the RZ/N1 SoCs can directly perform an
hardware reset using their dedicated reset line.

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.

This series adds support for this feature allowing watchdogs to directly
reset the system with any software needs when a watchdog timeout occurs.

The first two patches are minor fixes and improvements without changing
the current functional behavior.

Patches 3 to 5 add support for the feature adding:
  - The reset line description in the RZ/N1 watchdog binding,
  - A new helper at sysctrl level (sysctrl is handled by the clock
    driver in RZ/N1) to enable watchdog reset sources,
  - The support itself in the watchdog driver putting everything together.

Best regards,
Hervé

Herve Codina (Schneider Electric) (5):
  watchdog: rzn1: Fix reverse xmas tree declaration
  watchdog: rzn1: Use dev_err_probe()
  dt-bindings: watchdog: renesas,rzn1-wdt: Document the reset line
  clk: renesas: r9a06g032: Introduce a helper to set rsten register
  watchdog: rzn1: Add support for direct hardware reset

 .../bindings/watchdog/renesas,rzn1-wdt.yaml   | 22 +++++++
 drivers/clk/renesas/r9a06g032-clocks.c        | 32 ++++++++++
 drivers/watchdog/rzn1_wdt.c                   | 63 ++++++++++++++-----
 .../dt-bindings/watchdog/renesas,rzn1-wdt.h   | 16 +++++
 include/linux/soc/renesas/r9a06g032-sysctrl.h | 12 ++++
 5 files changed, 131 insertions(+), 14 deletions(-)
 create mode 100644 include/dt-bindings/watchdog/renesas,rzn1-wdt.h

-- 
2.53.0

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.

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?

Happy hacking,

   Wolfram

Hi Wolfram, Geert, Krzysztof

On Tue, 10 Mar 2026 22:53:01 +0100
Wolfram Sang <wsa+renesas@sang-engineering.com> 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é

> 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.

This would be configuration, not HW description, so not for DT. Also, I
think watchdogs are expected to reset the system. I'd see it as a quirk
if they can only raise an interrupt. So, let's go the full system reset
route, I'd say.

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

I see.

> 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.

Sounds totally fine to me.

Happy hacking,

   Wolfram