<div dir="ltr"><div dir="ltr">> There's a whole bunch of ways to schedule work in the kernel, it doesn't have to be<br>> a heartbeat function.<br>> <br>> Plenty of drivers are split into IRQ and non-IRQ parts (sometimes called the top and<br>> bottom parts of the driver).  See how they get info from the IRQ part to the non-IRQ part.<br class="gmail-Apple-interchange-newline"><br></div><div dir="ltr">I saw that this driver and others use workqueues to run longer functions outside of the irq handlers in the process context, so I tried scheduling a simple work struct that calls kernel_power_off() with this new patch:<div><a href="https://github.com/Abbotta4/linux/commit/008a720d9ffc31d5b60e0ca36f2aad0a04d50f0a">https://github.com/Abbotta4/linux/commit/008a720d9ffc31d5b60e0ca36f2aad0a04d50f0a</a></div><div>after reading up on workqueues a bit here:</div><div><a href="https://linux-kernel-labs.github.io/refs/heads/master/labs/deferred_work.html#workqueues">https://linux-kernel-labs.github.io/refs/heads/master/labs/deferred_work.html#workqueues</a><br></div><div>but the device still seems to hang at the blocking_notifier_call_chain() call. Is there something else I am missing here, other than leaving the irq context?</div><div><br></div><div>> But step back, why would this driver ever want to shut down the machine<br>> at all?  What problem are you trying to solve by making changes in this<br>> driver?<br></div><div><br></div><div>This change is to help the factory team test the devices before they are fully assembled. There are a series of tests that they run on different components and being able to unplug the device to trigger a shutdown is one of their priorities. I hope that sheds some light on the context of these patches and the strange functionality I am trying to implement. Sorry if it caused any confusion.</div><div><br></div><div>Thanks,</div><div>Drew</div></div></div>