On Feb 20, 2024 at 11:18:39 +0530, Maulik Shah (mkshah) wrote:
On 2/19/2024 10:59 PM, Lorenzo Pieralisi wrote:
On Mon, Feb 19, 2024 at 03:02:04PM +0530, Maulik Shah wrote:
psci_init_system_suspend() invokes suspend_set_ops() very early during bootup even before kernel command line for mem_sleep_default is setup. This leads to kernel command line mem_sleep_default=s2idle not working as mem_sleep_current gets changed to deep via suspend_set_ops() and never changes back to s2idle.
Move psci_init_system_suspend() to late_initcall() to make sure kernel command line mem_sleep_default=s2idle sets up s2idle as default suspend mode.
Why can't we fix it the other way around, namely enforce mem_sleep_current according to the mem_sleep_default command line even if suspend_set_ops() was already called ?
yes, this may be fixed other way also and i did not implement other way since mem_sleep_default_setup() only update mem_sleep_default and to avoid this race, it needs to also need to update mem_sleep_current along with it. Below change also resolves the issue.
--- a/kernel/power/suspend.c +++ b/kernel/power/suspend.c @@ -192,6 +192,7 @@ static int __init mem_sleep_default_setup(char *str) if (mem_sleep_labels[state] && !strcmp(str, mem_sleep_labels[state])) { mem_sleep_default = state;
mem_sleep_current = state; break; }however it may be erasing thin line between mem_sleep_default v/s mem_sleep_current as both gets updated while set up of mem_sleep_default.
if this change looks Ok, i can send v2 with it.
Honestly, I don't see too much of a problem with this, it only makes sense that we're starting off with a default sleep state which means that it will be considered as "current" sleep state.
For the issue that you described originally, I think this is a fine solution.
Just asking, I am not super keen on using initcalls ordering, it looks fragile to me.
i agree with above.
Same.