linux-kernel - Re: [PATCH 0/2] PM: domains: Add control for switching back and forth to HW control

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: <CAPDyKFoO85-k38-eXzJ3wRK9tfS=DfUw8-jE6fXORTVSoRLXzQ@mail.gmail.com>
Date:   Wed, 28 Jun 2023 23:55:54 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Abel Vesa <abel.vesa@...aro.org>,
        Kevin Hilman <khilman@...nel.org>, avel Machek <pavel@....cz>,
        Len Brown <len.brown@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Andy Gross <agross@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Mike Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Taniya Das <tdas@....qualcomm.com>, linux-pm@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH 0/2] PM: domains: Add control for switching back and forth
 to HW control

On Wed, 28 Jun 2023 at 19:15, Rafael J. Wysocki <rafael@...nel.org> wrote:
>
> On Wed, Jun 28, 2023 at 12:57 PM Abel Vesa <abel.vesa@...aro.org> wrote:
> >
> > This is just a resend of [1]. This resend just adds the back story behind
> > the need for such a generic API as a cover letter. Also added my SoB tag
> > to Ulf's patch.
> >
> > Some of the newer Qualcomm platforms support handing of the control of
> > some of the GDSCs (implemented as power domains in Linux) to some device
> > firmware. The idea behind such approach is that the firmware knows best
> > when such a power domain can be powered off or not and leads most of the
> > time to better power consumption.
> >
> > At this point, if such GDSC provides HW control support, the current
> > implementation is switching to HW control right after the GDSC gets
> > powered on and it is left in HW control mode until right before the
> > request for power off is done. This needs to remain as is for now, as we
> > do not know for sure what each firmware expects from its related GDSCs.
> > For example, the venus driver expects the codec GDSCs to remain always
> > in HW control mode, otherwise the firmware would crush.
> >
> > But in some cases, the consumer driver needs to switch back and forth.
> > And the explanation for such case is when a driver needs to interract
> > with the device (e.g. reading status bits) and the firmware doesn't
> > guarantee the GDSC will be enabled when in HW mode. Therefore, the
> > consumer would need to switch back to SW mode, do its thing, and then
> > switch again back to HW mode.
> >
> > This is where the patch from Ulf comes in. It allows consumers that
> > actually need to control the HW/SW mode to do so.
> >
> > The GDSC patch just implemets the set_hwmode op and sets it for each
> > GDSC that provides HW control mode.
> >
> > [1] https://lore.kernel.org/all/20230627104033.3345659-1-abel.vesa@linaro.org/
> >
> > Abel Vesa (1):
> >   clk: qcom: gdsc: Add support for set_hwmode_dev
> >
> > Ulf Hansson (1):
> >   PM: domains: Allow devices attached to genpd to be managed by HW
> >
> >  drivers/base/power/domain.c | 66 +++++++++++++++++++++++++++++++++++++
> >  drivers/clk/qcom/gdsc.c     | 22 +++++++++++++
> >  include/linux/pm_domain.h   | 15 +++++++++
> >  3 files changed, 103 insertions(+)
> >
> > --
>
> I can queue up this series if I get an ACK for the second patch.

Thanks, but please hold on until you get additional confirmation from me.

I would like the consumer APIs that are being added in patch1 to have
a user. At least I want to see a plan for upstreaming one user of it,
before I think we should move forward. FYI, there are discussions
around this offlist too.

Kind regards
Uffe