Hi Guenter and Rob,

On Tue, Jan 14, 2025 at 8:17 PM Guenter Roeck [off-list ref] wrote:

On 1/14/25 12:03, Rob Herring wrote:

quoted

On Mon, Jan 13, 2025 at 11:38:08AM +0000, Biju Das wrote:

quoted

Hi Prabhakar,

quoted

-----Original Message-----
From: Prabhakar <prabhakar.csengg@gmail.com>
Sent: 13 January 2025 11:24
Subject: [PATCH v3 0/6] Add support to retrieve the bootstatus from watchdog for RZ/V2H(P) SoC

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Hi All,

This patch series adds SYSCON support to retrieve boot status information for RZ/V2H(P) SoC.
Summary of Changes,

     Clock:
         Add syscon compatible support to the CPG block in bindings and
         device trees.

     Watchdog:
         Document the renesas,r9a09g057-syscon-wdt-errorrst property.
         Update the watchdog driver to fetch and report boot status via
         Error Reset Registers (CPG_ERROR_RSTm).

     Device Tree:
         Add the syscon property to CPG and WDT nodes in R9A09G057 and
         R9A09G047 SoC DTSI.

These changes enable the watchdog driver to identify boot sources like Power-on Reset and Watchdog
Reset, improving system diagnostics.

This means that, we should assume U-boot/bootloader should not clear the WDT reset status bit.

If they clear it, there should be a way to propagate it from u-boot/bootloader to linux,
otherwise, we get wrong bootstatus in linux.
But the clearing of watchdog status by one of the cases:

1) u-boot identify the boot source and clear the status bit
2) u-boot identify the boot source and does not clear the status bit, but linux clear it.
3) u-boot does not touch WDT status bits, but linux clear it.

Sounds like the same problem as this[1]. If that works for you, please
comment there. Always better if there is more than 1 user for something
"common".

Rob

[1]https://lore.kernel.org/devicetree-spec/48defa98-9718-4997-86cb-b171187708a6@cherry.de/T/#u (local)

If this ends up being provided through /chosen, it should probably be supported
in the watchdog core.

There wasn't any conclusion on the thread [0]. Can you please
recommend how you want me to proceed on this series.

[0] https://lore.kernel.org/devicetree-spec/48defa98-9718-4997-86cb-b171187708a6@cherry.de/T/#m2f1c7f5c8166522982cecf9351903ab06ca4f9ee (local)

Cheers,
Prabhakar