Unsupported Watchdogs

[Erdem Kahraman]

Hello community,

I want to use the efibootguard's watchdog by using a generic device.

There is too different hardwares and I want to activate the watchdog of ebg if it is supporting. 

But when I test it, if the watchdog device not existing or not supporting by ebg, the boot sequence gives error and exitting.

Is there any way to pass error if there is no watchdog or not supported watchdog?

[Jan Kiszka]

I'm not yet sure what exactly your are looking for, some recommendation
on how to debug a not-yet-working own driver in EBG? Or a better
understanding how EBG is matching a driver with the found hardware?

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux

[Erdem Kahraman]

I want to enable watchdog and I want success watchdog experience for several devices, And I want; if there is unsupported watchdog I want to say to ebg "never mind please go on"

But if there is any error like "Cannot probe watchdog (Unsupported)", I dont want to exit the boot.

Actually mentioning at code; I dont want to use as "error_exit" maybe it should be "WARNING" ?

I can pass this error by patching it but is there any other way?

3 Mayıs 2023 Çarşamba tarihinde saat 18:32:13 UTC+3 itibarıyla Jan Kiszka şunları yazdı:

[Jan Kiszka]

On 03.05.23 17:46, Erdem Kahraman wrote:
> I want to enable watchdog and I want success watchdog experience for
> several devices, And I want; if there is unsupported watchdog I want to
> say to ebg "never mind please go on"
>
> But if there is any error like "Cannot probe watchdog (Unsupported)", I
> dont want to exit the boot.
>
> Actually mentioning at code

> <https://github.com/siemens/efibootguard/blob/master/main.c#L177>; I

> dont want to use as "error_exit" maybe it should be "WARNING" ?
>
> I can pass this error by patching it but is there any other way?

If you install EBG on a device that EBG does not support or where the
firmware already enables the watchdog, just set the timeout to 0, and
EBG will skip watchdog handling.

Jan

>
> 3 Mayıs 2023 Çarşamba tarihinde saat 18:32:13 UTC+3 itibarıyla Jan
> Kiszka şunları yazdı:
>
> On 03.05.23 17:08, Erdem Kahraman wrote:
> > Hello community,
> >
> > I want to use the efibootguard's watchdog by using a generic device.
> >
> > There is too different hardwares and I want to activate the
> watchdog of
> > ebg if it is supporting. 
> >
> > But when I test it, if the watchdog device not existing or not
> > supporting by ebg, the boot sequence gives error and exitting.
> >
> > Is there any way to pass error if there is no watchdog or not
> supported
> > watchdog?
>
> I'm not yet sure what exactly your are looking for, some recommendation
> on how to debug a not-yet-working own driver in EBG? Or a better
> understanding how EBG is matching a driver with the found hardware?
>
> Jan
>
> --
> Siemens AG, Technology
> Competence Center Embedded Linux
>

> --
> You received this message because you are subscribed to the Google
> Groups "EFI Boot Guard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to efibootguard-d...@googlegroups.com
> <mailto:efibootguard-d...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Erdem Kahraman]

Great you are right but I am going to send the image to different devices.
I dont know is it supporting or not.
I just want to if it is supporting; yes please enable the watchdog, if it is not please go on.

In your case there is only one device to use, but it is a generic image for several different devices.
I can not be in interactive with device when the image sent to customer.

So I can not set the wdog timer as 0

Thanks

3 Mayıs 2023 Çarşamba tarihinde saat 18:50:02 UTC+3 itibarıyla Jan Kiszka şunları yazdı:

[Jan Kiszka]

On 03.05.23 17:55, Erdem Kahraman wrote:
> Great you are right but I am going to send the image to different devices.
> I dont know is it supporting or not.
> I just want to if it is supporting; yes please enable the watchdog, if
> it is not please go on.

That case was not in scope for EBG so far.

>
> In your case there is only one device to use, but it is a generic image
> for several different devices.
> I can not be in interactive with device when the image sent to customer.
>
> So I can not set the wdog timer as 0

Well, you effectively set it to 0 on all those devices that are not
supported yet. If someone uses such device in production AND something
goes wrong during an update, this would create a frozen device. In the
worst case, someone would even have to travel to it and perform a
power-cycle on-site. How will you address such a case in your user stories?

Jan

> https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com> <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
> --
> Siemens AG, Technology
> Competence Center Embedded Linux
>

> --
> You received this message because you are subscribed to the Google
> Groups "EFI Boot Guard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to efibootguard-d...@googlegroups.com
> <mailto:efibootguard-d...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/efibootguard-dev/592af421-2e69-4e9c-b1ca-585b9aa2cb9fn%40googlegroups.com <https://groups.google.com/d/msgid/efibootguard-dev/592af421-2e69-4e9c-b1ca-585b9aa2cb9fn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Erdem Kahraman]

>Well, you effectively set it to 0 on all those devices that are not
>supported yet. If someone uses such device in production AND something
>goes wrong during an update, this would create a frozen device. In the
>worst case, someone would even have to travel to it and perform a
>power-cycle on-site. How will you address such a case in your user stories?

Yes you are right the hardcoded way is so risky

I want to make it clear,
We can set a variable that is watchdog_may_fail = 1 at the runtime.
Then efibootguard will turn the error_exit to WARNING when this variable is set.
Wouldn't we be able to overcome this situation in this way?

Erdem Kahraman <rdm....@gmail.com>, 11 May 2023 Per, 12:21 tarihinde şunu yazdı:

>Well, you effectively set it to 0 on all those devices that are not
>supported yet. If someone uses such device in production AND something
>goes wrong during an update, this would create a frozen device. In the
>worst case, someone would even have to travel to it and perform a
>power-cycle on-site. How will you address such a case in your user stories?

Yes you are right the hardcoded way is so risky

I want to make it clear,
We can set a variable that is watchdog_may_fail = 1 at the runtime.
Then efibootguard will turn the error_exit to WARNING when this variable is set.
Wouldn't we be able to overcome this situation in this way?

Jan Kiszka <jan.k...@siemens.com>, 3 May 2023 Çar, 19:08 tarihinde şunu yazdı:

[Jan Kiszka]

On 11.05.23 11:24, Erdem Kahraman wrote:
>>Well, you effectively set it to 0 on all those devices that are not
>>supported yet. If someone uses such device in production AND something
>>goes wrong during an update, this would create a frozen device. In the
>>worst case, someone would even have to travel to it and perform a
>>power-cycle on-site. How will you address such a case in your user stories?
>
> Yes you are right the hardcoded way is so risky
>
> I want to make it clear,
> We can set a variable that is watchdog_may_fail = 1 at the runtime.
> Then efibootguard will turn the error_exit to WARNING when this variable
> is set.
> Wouldn't we be able to overcome this situation in this way?
>

This does not address the point I made: How do you ensure that this
degradation of safety is noticed by the user on devices not yet
supported by EBG? That might be more of an integration topic, but I'd
like to hear the complete story to asses if a certain feature extension
in EBG makes sense. And to be able to document that story in the end in
our README so that user do not misuse it accidentally.

Jan

>
> Erdem Kahraman <rdm....@gmail.com <mailto:rdm....@gmail.com>>, 11

> May 2023 Per, 12:21 tarihinde şunu yazdı:
>
> >Well, you effectively set it to 0 on all those devices that are not
> >supported yet. If someone uses such device in production AND something
> >goes wrong during an update, this would create a frozen device. In the
> >worst case, someone would even have to travel to it and perform a
> >power-cycle on-site. How will you address such a case in your user stories?
>
> Yes you are right the hardcoded way is so risky
>
> I want to make it clear,
> We can set a variable that is watchdog_may_fail = 1 at the runtime.
> Then efibootguard will turn the error_exit to WARNING when this
> variable is set.
> Wouldn't we be able to overcome this situation in this way?
>
>

> Jan Kiszka <jan.k...@siemens.com <mailto:jan.k...@siemens.com>>,

> >     > <mailto:efibootguard-d...@googlegroups.com

> <mailto:efibootguard-d...@googlegroups.com>>.
> >     > To view this discussion on the web visit
> >     >
> >   

>  https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com> <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com>> <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com?utm_medium=email&utm_source=footer>>>.

> >
> >     --
> >     Siemens AG, Technology
> >     Competence Center Embedded Linux
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "EFI Boot Guard" group.
> > To unsubscribe from this group and stop receiving emails from
> it, send
> > an email to efibootguard-d...@googlegroups.com

> <mailto:efibootguard-dev%2Bunsu...@googlegroups.com>
> > <mailto:efibootguard-d...@googlegroups.com
> <mailto:efibootguard-dev%2Bunsu...@googlegroups.com>>.

> > To view this discussion on the web visit
> >

> https://groups.google.com/d/msgid/efibootguard-dev/592af421-2e69-4e9c-b1ca-585b9aa2cb9fn%40googlegroups.com <https://groups.google.com/d/msgid/efibootguard-dev/592af421-2e69-4e9c-b1ca-585b9aa2cb9fn%40googlegroups.com> <https://groups.google.com/d/msgid/efibootguard-dev/592af421-2e69-4e9c-b1ca-585b9aa2cb9fn%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/efibootguard-dev/592af421-2e69-4e9c-b1ca-585b9aa2cb9fn%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
> --
> Siemens AG, Technology
> Competence Center Embedded Linux
>

> --
> You received this message because you are subscribed to the Google
> Groups "EFI Boot Guard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to efibootguard-d...@googlegroups.com
> <mailto:efibootguard-d...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/efibootguard-dev/CALk5RRsjsH-nYvvASOz%3DiobVr%3DmhCLOjzrdNa4O0j%2BqjMxN5qw%40mail.gmail.com <https://groups.google.com/d/msgid/efibootguard-dev/CALk5RRsjsH-nYvvASOz%3DiobVr%3DmhCLOjzrdNa4O0j%2BqjMxN5qw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Erdem Kahraman]

Okay the story is that;

In my case there is two different devices. You can think them like ubuntu and ubuntu installer. (not similar with ubuntu, I want to only show the hierarchy between the images)

These two images are using efibootguard as bootloader.

At the installer image, there is a program that is checking watchdog on the device.

I want to inform the user if there is any watchdogs are available to use.

After then if there is no watchdog to use, user has already took a warning like "WARNING: Cannnot probe watchdog".

If the user want to continue without the watchdog feature, user will proceed the installation without watchdog.

And the image (that is not installer) will set the watchdog timeout and also will set a variable at the runtime (I was thinking like that) watchdog_may_fail = 1 then even if there is a setted unsupported watchdog, it will not work.

In this case also we need to get "watchdog probed or not" info from userspace too. Because installer will inform the user about watchdog probe.

At the installer side I need to learn if there is a watchdog probed or not to inform the user.

At the image (that is not installer) side I need to set watchdog_may_fail = 1 because I'll put the image to the installer by default watchdog timeout setted.

11 Mayıs 2023 Perşembe tarihinde saat 12:31:01 UTC+3 itibarıyla Jan Kiszka şunları yazdı:

[Erdem Kahraman]

edit: There is not two different devices --> There is two different images.
         Installer (that is like ubuntu installer) including the image (that is like ubuntu)
         The installer image does not set the watchdog timeout by default.
         But the IMAGE (that is not installer) is setting the watchdog timeout by default.

11 Mayıs 2023 Perşembe tarihinde saat 13:07:27 UTC+3 itibarıyla Erdem Kahraman şunları yazdı:

[Henning Schild]

Hi,

i did not receive this one directly so the reply might look weird.

Thanks for the detailed explanation.

So you have an installer that flashes and also modifies/configures an
image. And you want to enable the whole watchdog chain if possible, but
want to still have a bootable device if that device would not yet be
supported by ebg, but by the linux-kernel.

Maybe a "manual retry run via installer" would be the best option.
So you flash the image and if it looks like watchdog support could work
you ask the user whether they want to enable that and modify that just
flashed image. If that does not work the user installs again and
answers a watchdog question with "please disable". That would require
potentially installing twice but would give users very clear feedback
on which of the devices the watchdog feature works and on which it did
not. All without having to change ebg, but only change "a postinstall
function".

installer code:
if ! exists /dev/watchdog*:
warn "watchdog not supported on this device"
else
enable_watchdog = user_dialog("enable watchdog?", default=true)
if enable_watchdog:
user_info("if that install fails to enable the watchdog in the
bootloader, please install again with watchdog feature disabled")
set bg_env timeout 60 (default was 0)
fi

You could also have a "enable/disable watchdog on previous install"
button in the installer user interaction. So people could change that
setting without having to re-install/flash.

But all that said, i still think it might be a nice feature for ebg to
not be so hard about that watchdog. For generic images that should work
anywhere, that is not acceptable. Where using the watchdog where
available is a nice mitigation of a certain arguably not too high risk.
Because only some classes of updates errors will require watchdog
support in the bootloader, while many other classes of errors can be
handled by the Linux kernel and its watchdog support just fine).

So one could add a new entry to that env, that would allow booting
without a watchdog even if a timeout is configured (as a wish but not a
need). A userinterface to give people feedback could be an on-screen
warning and a delay. But well ... on embedded there would be no screen
or nobody to look at it.

Henning

Henning

[Jan Kiszka]

On 11.05.23 12:18, Erdem Kahraman wrote:
> edit: There is not two different devices --> There is two different images.
>          Installer (that is like ubuntu installer) including the image
> (that is like ubuntu)
>          The installer image does not set the watchdog timeout by default.
>          But the IMAGE (that is not installer) is setting the watchdog
> timeout by default.

Got it. But why is your installer requiring EBG to boot? Why not simply
use systemd-boot for the installer, check with your program the
compatibility hardware and EBG, and then configure EBG in final image
with timeout=0 if the hardware is unsupported, the user was warned but
accepted this limitation?

Jan

>  https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com> <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com>> <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com> <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com>>> <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com?utm_medium=email&utm_source=footer>> <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/efibootguard-dev/15d7dcfc-906d-4b16-9930-e60a73efaff4n%40googlegroups.com?utm_medium=email&utm_source=footer>>>>.

> > >
> > >     --
> > >     Siemens AG, Technology
> > >     Competence Center Embedded Linux
> > >
> > > --
> > > You received this message because you are subscribed to the
> Google
> > > Groups "EFI Boot Guard" group.
> > > To unsubscribe from this group and stop receiving emails from
> > it, send
> > > an email to efibootguard-d...@googlegroups.com
> > <mailto:efibootguard-dev%2Bunsu...@googlegroups.com>
> > > <mailto:efibootguard-d...@googlegroups.com
> > <mailto:efibootguard-dev%2Bunsu...@googlegroups.com>>.
> > > To view this discussion on the web visit
> > >
> >

> https://groups.google.com/d/msgid/efibootguard-dev/592af421-2e69-4e9c-b1ca-585b9aa2cb9fn%40googlegroups.com <https://groups.google.com/d/msgid/efibootguard-dev/592af421-2e69-4e9c-b1ca-585b9aa2cb9fn%40googlegroups.com> <https://groups.google.com/d/msgid/efibootguard-dev/592af421-2e69-4e9c-b1ca-585b9aa2cb9fn%40googlegroups.com <https://groups.google.com/d/msgid/efibootguard-dev/592af421-2e69-4e9c-b1ca-585b9aa2cb9fn%40googlegroups.com>> <https://groups.google.com/d/msgid/efibootguard-dev/592af421-2e69-4e9c-b1ca-585b9aa2cb9fn%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/efibootguard-dev/592af421-2e69-4e9c-b1ca-585b9aa2cb9fn%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/efibootguard-dev/592af421-2e69-4e9c-b1ca-585b9aa2cb9fn%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/efibootguard-dev/592af421-2e69-4e9c-b1ca-585b9aa2cb9fn%40googlegroups.com?utm_medium=email&utm_source=footer>>>.

> >
> > --
> > Siemens AG, Technology
> > Competence Center Embedded Linux
> >
> > --
> > You received this message because you are subscribed to the
> Google
> > Groups "EFI Boot Guard" group.
> > To unsubscribe from this group and stop receiving emails from
> it, send
> > an email to efibootguard-d...@googlegroups.com
> > <mailto:efibootguard-d...@googlegroups.com>.
> > To view this discussion on the web visit
> >

> https://groups.google.com/d/msgid/efibootguard-dev/CALk5RRsjsH-nYvvASOz%3DiobVr%3DmhCLOjzrdNa4O0j%2BqjMxN5qw%40mail.gmail.com <https://groups.google.com/d/msgid/efibootguard-dev/CALk5RRsjsH-nYvvASOz%3DiobVr%3DmhCLOjzrdNa4O0j%2BqjMxN5qw%40mail.gmail.com> <https://groups.google.com/d/msgid/efibootguard-dev/CALk5RRsjsH-nYvvASOz%3DiobVr%3DmhCLOjzrdNa4O0j%2BqjMxN5qw%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/efibootguard-dev/CALk5RRsjsH-nYvvASOz%3DiobVr%3DmhCLOjzrdNa4O0j%2BqjMxN5qw%40mail.gmail.com?utm_medium=email&utm_source=footer>>.

>
> --
> Siemens AG, Technology
> Competence Center Embedded Linux
>

> --
> You received this message because you are subscribed to the Google
> Groups "EFI Boot Guard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to efibootguard-d...@googlegroups.com
> <mailto:efibootguard-d...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/efibootguard-dev/a9f4e750-89f6-45df-979f-0630f785450bn%40googlegroups.com <https://groups.google.com/d/msgid/efibootguard-dev/a9f4e750-89f6-45df-979f-0630f785450bn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Jan Kiszka]

That's why we support "timeout=0" - you can turn this feature of if you
take the risk. But it makes little sense to have a "best effort"
watchdog, even more as there is no easy way to spot that, at least so
far. It will only create more problems that it can solve.

Jan

>
> So one could add a new entry to that env, that would allow booting
> without a watchdog even if a timeout is configured (as a wish but not a
> need). A userinterface to give people feedback could be an on-screen
> warning and a delay. But well ... on embedded there would be no screen
> or nobody to look at it.
>
> Henning
>
> Henning
>

[Henning Schild]

Am Fri, 12 May 2023 12:25:41 +0200
schrieb Jan Kiszka <jan.k...@siemens.com>:

I am currently writing a new watchdog driver for IPMI watchdogs, found
i.e. in Supermicro and other server-class machines.

One needs to send two commands to a controller, and while doing so wait
several times for certain state-transitions. At the moment i
implemented the waiting as a busy waiting that would end up as an
endless loop should that controller for some reason enter an error
state. So far i have never seen any errors but they could potentially
happen any time, especially since such an IPMI BMC could be used by
others at the same time and there might be races.

So i will have to implement error handling and with it some retry
logic (sporadic errors). But also the retries will have to eventually
stop and i have to give up and decide on how to continue (temporary or
permanent errors). At which point i would likely have to signal just a
warning and continue booting. Simply because i have no clue whether i
am dealing with a temporary error (driver does not work this time, even
with retry logic) or a permanent one (driver never worked on that
machine).

Suggestions on how to deal with that are welcome, as i said i will
implement a "best effort with retry and eventual warning" and do my best
to test that.

At which point we would have one watchdog driver that in itself would
have potential to not being able to arm the watchdog, and we could
think about how such problems could be signaled to the OS.
But this would likely be patches on top. And "we have a driver that
failed (this time?)" is still something else than "we do not have a
driver at all".

Henning