linux-kernel - Re: [PATCH v2 4/4] PM: domains: Drop/restore performance state votes for devices at system PM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPDyKFrvrikCZLX1EvmLZumeCnfAxUUssO2OWc130TG8oey=qw@mail.gmail.com>
Date:   Tue, 8 Jun 2021 16:08:55 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Stephan Gerhold <stephan@...hold.net>,
        Mark Brown <broonie@...nel.org>
Cc:     "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Dmitry Osipenko <digetx@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Roja Rani Yarubandi <rojay@...eaurora.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Stephen Boyd <sboyd@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Rajendra Nayak <rnayak@...eaurora.org>
Subject: Re: [PATCH v2 4/4] PM: domains: Drop/restore performance state votes
 for devices at system PM

On Tue, 8 Jun 2021 at 14:53, Stephan Gerhold <stephan@...hold.net> wrote:
>
> Hi,
>
> On Thu, Jun 03, 2021 at 12:20:57PM +0200, Ulf Hansson wrote:
> > + Mark Brown, Dmitry Baryshkov
> >
> > On Thu, 3 Jun 2021 at 11:34, Ulf Hansson <ulf.hansson@...aro.org> wrote:
> > >
> > > Recent changes in genpd drops and restore performance state votes for
> > > devices during runtime PM.
> > >
> > > For the similar reasons, but to avoid the same kind of boilerplate code in
> > > device PM callbacks for system sleep in subsystems/drivers, let's drop and
> > > restore performance states votes in genpd for the attached devices during
> > > system sleep.
> > >
> > > Signed-off-by: Ulf Hansson <ulf.hansson@...aro.org>
> >
> > After a second thought, it looks like we maybe should defer to apply
> > this final patch of the series. At least until we figured out how to
> > address the below issue:
> >
> > So, I noticed that we have things like "regulator-fixed-domain", that
> > uses "required-opps" to enable/disable a regulator through the
> > dev_pm_set_performance_state() interface.
>
> Not directly related to your concern, but related to another discussion
> we had recently: To me, this looks mostly like another solution for
> voting for performance states without doing full DVFS, also known as
> assigned-performance-states [1] or required-opps on devices [2]. :)
>
> It's just wrapped in a regulator interface here. Actually, if we
> implement [2], the regulator-fixed-domain should mostly just become some
> sort of simple wrapper around runtime PM for the regulator device, since
> the required-opp might be applied automatically then.

Honestly, I am not sure about what the regulator-fixed-domain intends
to model, but I assume it's something that fits well to be modelled as
a plain regulator, to start with.

Perhaps Mark can chime in and spread some light over this?

>
> [1]: https://lore.kernel.org/linux-arm-msm/1622095949-2014-1-git-send-email-rnayak@codeaurora.org/
> [2]: https://lore.kernel.org/linux-arm-msm/YLYV3ov%2FiBffZMg4@gerhold.net/
>
> > We likely don't want to drop the performance state internally in genpd
> > when genpd_suspend_noirq() gets called, for the corresponding struct
> > device for the regulator.
> >
>
> So your concern is that the performance state is dropped during suspend
> even though the regulator core thinks the regulator stays enabled?

Yes.

>
> I played with regulator-fixed-domain a bit and I would say this is
> already broken (unless you rely on one of the side effects I mentioned
> in [3]). The power domain gets powered off entirely during system
> suspend, and then the performance state won't have any effect either.

Right, I get your point.

Although, this isn't a problem, because the on/off and performance
states are today considered as orthogonal in gendp. Well, at least
currently until/if we decide to change this.

>
> I guess we would need some way to say that this device should only be
> managed through runtime PM and never automatically suspended during
> system suspend?

Yes!

For the on/off state, genpd uses the system wakeup interface to
understand whether the device is used in a wakeup path, see the call
to device_wakeup_path() in genpd_finish_suspend().
If that's the case the PM domain stays powered on during system suspend.

Potentially we could use the same interface (or something similar) to
support these kinds of cases.

>
> Stephan
>
> [3]: https://lore.kernel.org/linux-pm/YLkOAyydZMnxkEy+@gerhold.net/

Kind regards
Uffe