Re: [PATCH 0/3] watchdog: omap: Preserve OMAP watchdog across boot to detect faulty boots

[Guenter Roeck]

On 9/11/26 08:17, Diogo Ivo wrote:
> Hi Guenter,
>
> On 9/11/26 4:29 PM, Guenter Roeck wrote:
> > On 9/11/26 02:17, Diogo Ivo wrote:
> > > Allow the OMAP watchdog to survive being stopped on kernel initialization
> > > so it can detect a faulty boot in cases where the bootloader leaves it
> > > running and the watchdog driver picks it up during kernel init.
> > >
> > > - Patch 1 removes a duplicate omap_wdt_start() call left behind by
> > > cd004d8299f1 ("watchdog: Fix OMAP watchdog early handling"). This is
> > > unrelated to the main goal of the series and can be picked up
> > > independently.
> > >
> > > - Patch 2 adds support for reading the watchdog boot status. Probe now
> > > checks whether the watchdog is already running and takes it over instead
> > > of blindly stopping it based on early_enable alone. This introduces a
> > > regression possibility, explained in detail in the patch's message.
> > >
> > > - Patch 3 marks the OMAP4 watchdog node ti,no-reset-on-init so the
> > > ti-sysc driver stops resetting it. A detailed explaination of why is
> > > also provided in the commit message of the patch.
> > >
> > > This series has been tested on a platform based on the VAR-SOM-OM44 from
> > > Variscite, running a TI OMAP4460 SoC.
> > Please address the issues reported by Sashiko, or explain why they don't apply.
>
> I have just replied to the Sashiko reviews but I'm not sure if you got
> the replies as Sashiko did not include your e-mail in its review. If you
> did not receive them please let me know and I can resend them. In
> any case if you could give your opinion on the comments I left on the
> patches about regressions that would be great as I think after the
> Sashiko points are addressed that is the main blocker for this series.
I did. I just wonder if the effort is worth the pain / cost.

Is there an actual use case ? Is the problem you are trying to solve
a real problem, or a theoretic one ? For example, the patches impose
a hard boot delay of more than 30 ms in omap_wdt_is_running().
Even though that could be optimized (there is no reason to wait
that long; the value could change a microsecond after the first read),
it is nevertheless a mandatory boot delay.

Another concern is the impact and potential side effects of setting
ti,no-reset-on-init (and the possible boot loop cause by it due to the odd
30-second init delay). After this change, a running watchdog is no longer
stopped. What happens on systems which do not load the watchdog at all
(for example because the driver was not configured) ? Will that also cause
a boot loop on such systems ?

This is just a couple of problems introduced by this series. You better have
a very good reason for it to warrant having to deal with the potential fallout.

Thanks,
Guenter