Re: Kernel module that shuts down the device

[Drew Abbott <abbotta4@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1451 bytes --]

> There's a whole bunch of ways to schedule work in the kernel, it doesn't
have to be
> a heartbeat function.
>
> Plenty of drivers are split into IRQ and non-IRQ parts (sometimes called
the top and
> bottom parts of the driver).  See how they get info from the IRQ part to
the non-IRQ part.

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:
https://github.com/Abbotta4/linux/commit/008a720d9ffc31d5b60e0ca36f2aad0a04d50f0a
after reading up on workqueues a bit here:
https://linux-kernel-labs.github.io/refs/heads/master/labs/deferred_work.html#workqueues
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?

> But step back, why would this driver ever want to shut down the machine
> at all?  What problem are you trying to solve by making changes in this
> driver?

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.

Thanks,
Drew

[-- Attachment #1.2: Type: text/html, Size: 1945 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies