| Message ID | 20240219-suspend_ops_late_init-v1-1-6330ca9597fa@quicinc.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | firmware/psci: Move psci_init_system_suspend() to late_initcall() | expand |
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 ? Just asking, I am not super keen on using initcalls ordering, it looks fragile to me. Thanks, Lorenzo > Fixes: faf7ec4a92c0 ("drivers: firmware: psci: add system suspend support") > CC: stable@vger.kernel.org # 5.15+ > Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com> > --- > drivers/firmware/psci/psci.c | 13 ++++++++++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c > index d9629ff87861..655a2db70a67 100644 > --- a/drivers/firmware/psci/psci.c > +++ b/drivers/firmware/psci/psci.c > @@ -523,18 +523,26 @@ static void __init psci_init_system_reset2(void) > psci_system_reset2_supported = true; > } > > -static void __init psci_init_system_suspend(void) > +static int __init psci_init_system_suspend(void) > { > int ret; > + u32 ver; > > if (!IS_ENABLED(CONFIG_SUSPEND)) > - return; > + return 0; > + > + ver = psci_0_2_get_version(); > + if (PSCI_VERSION_MAJOR(ver) < 1) > + return 0; > > ret = psci_features(PSCI_FN_NATIVE(1_0, SYSTEM_SUSPEND)); > > if (ret != PSCI_RET_NOT_SUPPORTED) > suspend_set_ops(&psci_suspend_ops); > + > + return ret; > } > +late_initcall(psci_init_system_suspend) > > static void __init psci_init_cpu_suspend(void) > { > @@ -651,7 +659,6 @@ static int __init psci_probe(void) > if (PSCI_VERSION_MAJOR(ver) >= 1) { > psci_init_smccc(); > psci_init_cpu_suspend(); > - psci_init_system_suspend(); > psci_init_system_reset2(); > kvm_init_hyp_services(); > } > > --- > base-commit: d37e1e4c52bc60578969f391fb81f947c3e83118 > change-id: 20240219-suspend_ops_late_init-27fb0b15baee > > Best regards, > -- > Maulik Shah <quic_mkshah@quicinc.com> >
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. > > Just asking, I am not super keen on using initcalls ordering, it > looks fragile to me. i agree with above. Thanks, Maulik
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.
diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c index d9629ff87861..655a2db70a67 100644 --- a/drivers/firmware/psci/psci.c +++ b/drivers/firmware/psci/psci.c @@ -523,18 +523,26 @@ static void __init psci_init_system_reset2(void) psci_system_reset2_supported = true; } -static void __init psci_init_system_suspend(void) +static int __init psci_init_system_suspend(void) { int ret; + u32 ver; if (!IS_ENABLED(CONFIG_SUSPEND)) - return; + return 0; + + ver = psci_0_2_get_version(); + if (PSCI_VERSION_MAJOR(ver) < 1) + return 0; ret = psci_features(PSCI_FN_NATIVE(1_0, SYSTEM_SUSPEND)); if (ret != PSCI_RET_NOT_SUPPORTED) suspend_set_ops(&psci_suspend_ops); + + return ret; } +late_initcall(psci_init_system_suspend) static void __init psci_init_cpu_suspend(void) { @@ -651,7 +659,6 @@ static int __init psci_probe(void) if (PSCI_VERSION_MAJOR(ver) >= 1) { psci_init_smccc(); psci_init_cpu_suspend(); - psci_init_system_suspend(); psci_init_system_reset2(); kvm_init_hyp_services(); }
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. Fixes: faf7ec4a92c0 ("drivers: firmware: psci: add system suspend support") CC: stable@vger.kernel.org # 5.15+ Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com> --- drivers/firmware/psci/psci.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) --- base-commit: d37e1e4c52bc60578969f391fb81f947c3e83118 change-id: 20240219-suspend_ops_late_init-27fb0b15baee Best regards,