Messages in this thread | | | From | Michael Ellerman <> | Subject | Re: [PATCH v1] kernel/reboot: Change registration order of legacy power-off handler | Date | Mon, 06 Jun 2022 23:06:23 +1000 |
| |
Dmitry Osipenko <dmitry.osipenko@collabora.com> writes: > Hi Michael, > > On 6/5/22 05:01, Michael Ellerman wrote: >> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes: >>> We're unconditionally registering sys-off handler for the legacy >>> pm_power_off() callback, this causes problem for platforms that don't >>> use power-off handlers at all and should be halted. Now reboot syscall >>> assumes that there is a power-off handler installed and tries to power >>> off system instead of halting it. >>> >>> To fix the trouble, move the handler's registration to the reboot syscall >>> and check the pm_power_off() presence. >> >> I'm seeing a qemu virtual machine (ppce500) fail to power off using the >> gpio-poweroff driver. I bisected it to this commit. >> >> I think the problem is that the machine is going via kernel_power_off(), >> not sys_reboot(), and so legacy_pm_power_off() has not been registered. >> >> If I just put the core_initcall back then it works as before. Not sure >> if that's a safe change in general though. > > Thank you very much for the testing and reporting the problem! I see now the two more cases that were missed previously: > > 1. There is the orderly_poweroff() used by some drivers. > 2. PowerPC may invoke do_kernel_power_off() directly from xmon code. > > Could you please test this change:
That works, thanks.
I tested both sysrq-o and the xmon power off path.
I couldn't come up with an easy way to test the orderly_poweroff() path, but it boils down to basically the same code in the end.
Tested-by: Michael Ellerman <mpe@ellerman.id.au>
cheers
| |