Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200422051529.30757-1-zhang.lyra@gmail.com> <CAJZ5v0ikL3avFomZVqtBhfEjeauN-5ZUm9kZwzG=Vo+Ks0AiyA@mail.gmail.com>
In-Reply-To: <CAJZ5v0ikL3avFomZVqtBhfEjeauN-5ZUm9kZwzG=Vo+Ks0AiyA@mail.gmail.com>
From:   Chunyan Zhang <zhang.lyra@gmail.com>
Date:   Wed, 22 Apr 2020 19:18:45 +0800
Message-ID: <CAAfSe-sVEEPOrq_ZzB1z59uXTfhmNh=+U_QvgaTcd4U1=9Tfvg@mail.gmail.com>
Subject: Re: [PATCH] PM: sleep: call devfreq_suspend/resume and
 cpufreq_suspend/resume in pairs.
To:     "Rafael J. Wysocki" <rafael@kernel.org>
Cc:     "Rafael J . Wysocki" <rjw@rjwysocki.net>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
        Linux PM <linux-pm@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Orson Zhai <orsonzhai@gmail.com>,
        Vincent Wang <vincent.wang@unisoc.com>,
        Samer Xie <samer.xie@unisoc.com>,
        Chunyan Zhang <chunyan.zhang@unisoc.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Rafael,

(Behalf Of Vincent Wang)

Thanks for your comments, please see my answers below.

On Wed, 22 Apr 2020 at 17:05, Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Wed, Apr 22, 2020 at 7:15 AM Chunyan Zhang <zhang.lyra@gmail.com> wrot=
e:
> >
> > From: Vincent Wang <vincent.wang@unisoc.com>
> >
> > 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?

Yes=EF=BC=8Cwe found an issue with cpufreq schedutil governor on kernel4.14=
,
and I think the issue should haven't been changed on the latest
version of kernel.

In the function dpm_suspend_start(), dpm_suspend() would not be
exceuted if return error from device_prepare() [1]. So
cpufreq_cpufreq() will not be called, then
cpufreq_remove_update_util_hook() will not be called either, and so
cpufreq_update_util_data will not be NULL.

In the dpm resume flow, sugov_start() will be called, in which
sg_cpu.update_util will be set to 0.

And since cpufreq_update_util_data is not NULL, data->func will not be
set and is still NULL which actually is sg_cpu.update_util.

void cpufreq_add_update_util_hook(int cpu, struct update_util_data *data,
                        void (*func)(struct update_util_data *data, u64 tim=
e,
                                     unsigned int flags))
{
[...]
        if (WARN_ON(per_cpu(cpufreq_update_util_data, cpu)))
                return;

        data->func =3D func;
[...]
}

When cpufreq_update_util() is called by scheduler, there will be a
NULL pointer issue.


[1] https://elixir.bootlin.com/linux/v5.7-rc1/source/drivers/base/power/mai=
n.c#L2052


>
> > Signed-off-by: Vincent Wang <vincent.wang@unisoc.com>
> > Signed-off-by: Samer Xie <samer.xie@unisoc.com>
> > Signed-off-by: Chunyan Zhang <zhang.lyra@gmail.com>
> > ---
> >  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 =3D state;
> >         async_error =3D 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
> >