watchdog: Add Broadcom BCM2711 watchdog timer driver

[popcornmix]

This adds a driver for watchdog timer hardware present on Broadcom BCM2711
and BCM2712 SoC, used in Raspberry Pi 4 and 5 devices.

While the existing BCM2835 driver does work on these parts,
the new peripheral increases the maximum timeout from ~15s
to ~159s which can be useful.

[popcornmix]

This is for comments. It's a little ugly how this goes through the existing pm driver.

Rather than a separate watchdog driver, I wonder if it may be better to merge them,
and just have the register write (which is small part of driver) conditional based on DT.

[pelwell]

It's a little ugly how this goes through the existing pm driver.

What do you think is the purpose of the interlinking? Is there anything stopping us instantiating the WDT directly from DT?

[popcornmix]

What do you think is the purpose of the interlinking? Is there anything stopping us instantiating the WDT directly from DT?

It looks like the main reason is power (bcm2835-power) and watchdog (bcm2835-wdt) share a peripheral block.
A parent (brcm,bcm2835-pm-wdt) mfd driver actually registers the peripheral block (Power Manager) and passes the registers to the two sub drivers (power and wdt).

But I don't see any locking wrapper, that would mean this design was necessary. But perhaps it's considered more correct.

But main reason is upstream chose this implementation, and following their pattern seems wise.

[lategoodbye]

In case maximum timeout is the only reason, there is a fix for the bcm2835_wdt which let the kernel take care of keeping alive for longer timeouts:
https://lore.kernel.org/linux-watchdog/[email protected]/T/

[popcornmix]

@lategoodbye thank - that is interesting. The limited watchdog duration is the main reason for considering this driver switch.

I guess you patch may get an earlier (15s) than expected watchdog reboot if the core watchdog code dies, but that's probably a pretty fatal situation anyway, so a reset isn't unreasonable.