summaryrefslogtreecommitdiff
path: root/drivers/watchdog/gpio_wdt.c
AgeCommit message (Collapse)Author
2022-09-27watchdog: gpio_wdt: use __udelay() to avoid recursionRasmus Villemoes
The udelay() function in lib/time.c contains a WATCHDOG_RESET() call. The only reason this doesn't lead to a catastrophic infinite recursion is due to the rate-limiting in wdt-uclass.c: if (time_after_eq(now, priv->next_reset)) { priv->next_reset = now + priv->reset_period; wdt_reset(dev); } But this would fall apart if ->next_reset was updated after calling the device's reset method. This is needlessly fragile, and it's easy enough to avoid that recursion in the first place by just using __udelay() directly. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Stefan Roese <sr@denx.de>
2022-07-21watchdog: add pulse support to gpio watchdog driverPaul Doelle
A common external watchdog circuit is kept alive by triggering a short pulse on the reset pin. This patch adds support for this use case, while making the algorithm configurable in the devicetree. The "linux,wdt-gpio" driver being modified is based off the equivalent driver in the Linux kernel, which provides support for this algorithm. This patch brings parity to this driver, and is kept aligned with the functionality and devicetree configuration in the kernel. It should be noted that this adds a required property named 'hw_algo' to the devicetree binding, following suit with the kernel. I'm happy to make this backward-compatible if preferred. Signed-off-by: Paul Doelle <paaull.git@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2021-08-31watchdog: add gpio watchdog driverRasmus Villemoes
A rather common kind of external watchdog circuit is one that is kept alive by toggling a gpio. Add a driver for handling such a watchdog. The corresponding linux driver apparently has support for some watchdog circuits which can be disabled by tri-stating the gpio, but I have never actually encountered such a chip in the wild; the whole point of adding an external watchdog is usually that it is not in any way under software control. For forward-compatibility, and to make DT describe the hardware, the current driver only supports devices that have the always-running property. I went a little back and forth on whether I should fail ->probe or only ->start, and ended up deciding ->start was the right place. The compatible string is probably a little odd as it has nothing to do with linux per se - however, I chose that to make .dts snippets reusable between device trees used with U-Boot and linux, and this is the (only) compatible string that linux' corresponding driver and DT binding accepts. I have asked whether one should/could add "wdt-gpio" to that binding, but the answer was no: https://lore.kernel.org/lkml/CAL_JsqKEGaFpiFV_oAtE+S_bnHkg4qry+bhx2EDs=NSbVf_giA@mail.gmail.com/ If someone feels strongly about this, I can certainly remove the "linux," part from the string - it probably wouldn't the only place where one can't reuse a DT snippet as-is between linux and U-Boot. Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stefan Roese <sr@denx.de> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>