2024-02-19 09:33:07

by Maulik Shah (mkshah)

[permalink] [raw]
Subject: [PATCH] firmware/psci: Move psci_init_system_suspend() to late_initcall()

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: [email protected] # 5.15+
Signed-off-by: Maulik Shah <[email protected]>
---
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 <[email protected]>



2024-02-19 17:29:41

by Lorenzo Pieralisi

[permalink] [raw]
Subject: Re: [PATCH] firmware/psci: Move psci_init_system_suspend() to late_initcall()

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: [email protected] # 5.15+
> Signed-off-by: Maulik Shah <[email protected]>
> ---
> 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 <[email protected]>
>

2024-02-20 05:49:20

by Maulik Shah (mkshah)

[permalink] [raw]
Subject: Re: [PATCH] firmware/psci: Move psci_init_system_suspend() to late_initcall()



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

2024-02-23 09:04:53

by Dhruva Gole

[permalink] [raw]
Subject: Re: [PATCH] firmware/psci: Move psci_init_system_suspend() to late_initcall()

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.


--
Best regards,
Dhruva Gole <[email protected]>