[PATCH 2/2] watchdog: add watchdog behavior configuration

[Tom Rini <trini@konsulko.com>]

On Sun, Oct 04, 2020 at 05:10:32PM +0200, Heinrich Schuchardt wrote:
> Am 4. Oktober 2020 16:55:32 MESZ schrieb Michael Walle <michael@walle.cc>:
> >Hi all,
> >
> >Am 2020-09-25 15:04, schrieb Wolfgang Denk:
> >> Dear Heinrich Schuchardt,
> >> 
> >> In message <ceeb82b7-eef0-7435-0d0c-958c0bf07e04@gmx.de> you wrote:
> >>> 
> >>> > Any so-called "watchdog" that can be disabled / switched off by
> >>> > software is not really woth this name.  As such, the concept of
> >>> > disabling a watchdog in software, is misleading at best and should
> >>> > never ibe implemented.
> >>> 
> >>> If we want to boot UEFI payloads, we will have to follow the UEFI
> >>> specification even if we think it is not perfect.
> >> 
> >> That's perfectly OK.  But if the OS expects that the watchdog is
> >> disabled, then we should not enable it in U-Boot in the first place.
> >> 
> >> Keep in ind that any real watchdog (which is worth the money and the
> >> name) _cannot_ be disabled by software once it was started.
> >
> >How do we proceed here? There seems to be no final conclusion what to
> >do.
> >
> >I guess one thing we agree on is that after a system is booted with
> >bootefi the watchdog should be disabled. So Wolfgang argues, that the
> >watchdog shouldn't be enabled in the first place then. With this patch
> >this would actually be possible, the user could just choose to not
> >enable it at all; if he has a watchdog which can be disabled again,
> >he can choose that behavior too.
> >
> >OTOH Mark argues, that in the bootefi case, the watchdog should be
> >disabled in _any_ case. But that would mean to change the behavior
> >of current boards. So the question is: is this acceptable?
> >
> >So if this is not acceptable, I don't think there will be any
> >changes to this patch (otherwise than having some additional help
> >text).
> >
> >If it is acceptable, I'd stop the watchdog before bootefi
> >unconditionally (and printing a message if SUPERVISE_OS is set), but
> >keep the current logic for bootm. Personally I'd also prefer this,
> >because in the end you'll have a bootloader which can boot an OS via
> >EFI in any case.
> >
> >Tom, you've mentioned the IMX_WATCHDOG with !CONFIG_WDT. One key
> >difference is that without CONFIG_WDT the watchdog is only started
> >if CONFIG_WATCHDOG is enabled (or I missed something here). And I
> >don't think this patch will apply for that case, right? I think
> >in that case the watchdog can't even be stopped; there seems to be
> >only functions to initialize and kick it. Therefore, it also won't
> >be compatible the EFI spec. There might be warning during the build
> >if HW_WATCHDOG && EFI_LOADER is set. With a note which suggest the
> >move to CONFIG_WDT.
> >
> >-michael
> 
> For the UEFI side the constraint is: do not arm any watchdog that is
> not disarmed in efi_exitboot_services() or has an initial timeout  <
> 300s or is not adjusted or disarmed by efi_set_watchdog().

Which in turn means that UEFI fails to consider most modern SoCs.  I
think we'll need to state somewhere that for some cases we simply aren't
compliant.  That's not to say we shouldn't have a way to be compliant
when possible.  With that IMX_WATCHDOG case, I too need to dig in a bit
to see how it works really in that case as I thought I saw that we were
servicing the watchdog, always.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20201004/2dd09bf0/attachment.sig>