Re: [PATCH] PM: sleep: call devfreq_suspend/resume and cpufreq_suspend/resume in pairs.

[Rafael J. Wysocki]

On Wed, Apr 22, 2020 at 7:15 AM Chunyan Zhang <zhang.lyra@xxxxxxxxx> wrote:
>
> From: Vincent Wang <vincent.wang@xxxxxxxxxx>
>
> If dpm_prepare() fails in dpm_suspend_start(), dpm_suspend() can't be
> called.

That's correct.

> And then, devfreq_suspend() and cpufreq_suspend() will not be
> called in the suspend flow.

Right.

> But in the resiume flow, devfreq_resume() and cpufreq_resume() will
> be called.

Right, and they are expected to cope with the situation.

> This patch will ensure that devfreq_suspend/devfreq_resume and
> cpufreq_suspend/cpufreq_resume are called in pairs.

So why is it better to do this than to make devfreq_resume() meet the
expectations?

> Signed-off-by: Vincent Wang <vincent.wang@xxxxxxxxxx>
> Signed-off-by: Samer Xie <samer.xie@xxxxxxxxxx>
> Signed-off-by: Chunyan Zhang <zhang.lyra@xxxxxxxxx>
> ---
>  drivers/base/power/main.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index fdd508a78ffd..eb3d987d43e0 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -1866,9 +1866,6 @@ int dpm_suspend(pm_message_t state)
>         trace_suspend_resume(TPS("dpm_suspend"), state.event, true);
>         might_sleep();
>
> -       devfreq_suspend();
> -       cpufreq_suspend();
> -
>         mutex_lock(&dpm_list_mtx);
>         pm_transition = state;
>         async_error = 0;
> @@ -1988,6 +1985,9 @@ int dpm_prepare(pm_message_t state)
>         trace_suspend_resume(TPS("dpm_prepare"), state.event, true);
>         might_sleep();
>
> +       devfreq_suspend();
> +       cpufreq_suspend();
> +
>         /*
>          * Give a chance for the known devices to complete their probes, before
>          * disable probing of devices. This sync point is important at least
> --
> 2.20.1
>