> 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.
> 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:
after reading up on workqueues a bit here:
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?
> 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
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
