On 6/6/22 16:06, Michael Ellerman wrote: > Dmitry Osipenko <dmitry.osipe...@collabora.com> writes: >> Hi Michael, >> >> On 6/5/22 05:01, Michael Ellerman wrote: >>> Dmitry Osipenko <dmitry.osipe...@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 <m...@ellerman.id.au> > > cheers
Awesome, thank you! -- Best regards, Dmitry
