On 17/03/2021 22.35, Matt Spinler wrote: > > > On 3/17/2021 3:42 PM, Rasmus Villemoes wrote: >> On 15/03/2021 23.41, dewelo...@wp.pl wrote: >>> Dnia 2021-03-15, o godz. 08:26:38 >>> Matt Spinler <mspin...@linux.ibm.com> napisał(a): >>> >> for not responding sooner. >>>> In my case, the code is on a BMC (OpenBMC), and the output of the >>>> watchdog is wired to a fan watchdog hardware circuit (involving a latch >>>> and a standalone fan control chip), which the watchdog app is pinging. >>>> So if the watchdog app dies the fans get set to full speed, however on >>>> the next main power cycle of the server (the BMC is on a different >>>> power >>>> domain) we want things back to normal, so the watchdog has to work >>>> again >>>> when it is restarted, which it wasn't doing without my change. >> Thanks for the explanation. Can you point me at the watchdog driver code >> which does this "get things back to normal" on a (graceful) >> shutdown/stop? > > Our hardware is an ASPEED BMC chip, and here is the driver: > https://github.com/torvalds/linux/blob/master/drivers/watchdog/aspeed_wdt.c
[That reminds me, I reported a bug in that driver long ago: https://lore.kernel.org/lkml/20190812131356.23039-1-li...@rasmusvillemoes.dk/ Probably not related, but given that you have the hardware, you might be interested in getting it fixed.] But I don't understand how the userspace work-around can have any effect (note: I'm not doubting you, this is all just curiosity on my part). The only thing that's done in _stop() is to clear the WDT_CTRL_ENABLE bit. But the first time you open the device (or possibly during _probe() if the kernel finds the WDT_CTRL_ENABLE bit set), aspeed_wdt_enable() is called, which as the very first thing does writel(0, wdt->base + WDT_CTRL);, which certainly clears the WDT_CTRL_ENABLE bit. The driver also has a comment /* * The watchdog is running, but invoke aspeed_wdt_start() to * write wdt->ctrl to WDT_CTRL to ensure the watchdog's * configuration conforms to the driver's expectations. * Primarily, ensure we're using the 1MHz clock source. */ but if that doesn't work as intended, clearly it's the driver that needs patching. Rasmus _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox