PhilE wrote: ↑
Mon Oct 01, 2018 9:03 am
The gpio-poweroff driver is built into the kernel and loaded very early. The gpio-keys driver that implements gpio-shutdown is a module and loaded after the rootfs goes read/write. Making gpio-keys load earlier may be possible, but there has to be a system process running to detect the power-off key being pressed and trigger a shutdown, so it probably won't make any practical difference.
Thanks, that's good info.
Let's see if I've got this right. Initially, a falling edge on GPIO3 will do nothing. Once gpio-keys is loaded, a falling edge on GPIO3 will send a power key event, but it goes into the bit bucket. Once systemd has started a process that listens for the power key event, a falling edge on GPIO3 will send that event, and that process will run a script that tells systemd to shut the system down.
It sounds like none of these occurrences are buffered in any way, so it isn't sufficient just to hold GPIO3 low and wait for something to happen, or even to generate an edge after gpio-keys is loaded. It sounds like an actual falling edge must be generated after both gpio-keys is loaded and systemd has started the shutdown monitoring process. Is that right?
If that's true, then I have no choice but to assume it's never safe to yank the power, and to assume that something will be ready to respond to a shutdown request soon but not necessarily right now. The only solution I see is to have my circuit generate a pulse train that keeps trying to initiate a shutdown until it eventually responds. The easiest thing to do would be to gate some existing clock into GPIO3--the Ethernet/USB chip has both 25MHz and 24MHz available. Do you think that hitting an IRQ GPIO at that rate would bring the system to its knees?