linux-kernel - Re: [PATCH v1 0/5] power: domain: Add driver for a PM domain provider which controls

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: <CAPDyKFrEYCx3L94gz27Pk_=HdwA4GNGE9Lvz+HGUW0P7Qt-mBw@mail.gmail.com>
Date:   Wed, 13 Jul 2022 13:43:28 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Max Krummenacher <max.oss.09@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>
Cc:     Max Krummenacher <max.krummenacher@...adex.com>,
        Linux PM list <linux-pm@...r.kernel.org>,
        Francesco Dolcini <francesco.dolcini@...adex.com>,
        Mark Brown <broonie@...nel.org>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Kevin Hilman <khilman@...nel.org>,
        Andrejs Cainikovs <andrejs.cainikovs@...adex.com>,
        Biju Das <biju.das.jz@...renesas.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Fabio Estevam <festevam@...il.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Marcel Ziswiler <marcel.ziswiler@...adex.com>,
        NXP Linux Team <linux-imx@....com>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Rob Herring <robh+dt@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Shawn Guo <shawnguo@...nel.org>, Vinod Koul <vkoul@...nel.org>,
        Will Deacon <will@...nel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 0/5] power: domain: Add driver for a PM domain provider
 which controls

On Thu, 23 Jun 2022 at 18:14, Max Krummenacher <max.oss.09@...il.com> wrote:
>
> Hi all
>
> On Thu, Jun 16, 2022 at 2:51 PM Linus Walleij <linus.walleij@...aro.org> wrote:
> >
> > On Thu, Jun 9, 2022 at 5:10 PM Max Krummenacher <max.oss.09@...il.com> wrote:
> >
> > > This series adds a PM domain provider driver which enables/disables
> > > a regulator to control its power state.
> >
> > Actually, we did this on the U8500 in 2011.
> >
> > IIRC this led to problems because we had to invent "atomic regulators"
> > because regulators use kernel abstractions that assume slowpath
> > (process context) and power domains does not, i.e. they execute in
> > fastpath, such as an interrupt handler.

This isn't entirely correct. The callbacks of a genpd, *may* execute
in atomic context, but that depends on whether the GENPD_FLAG_IRQ_SAFE
is set for it or not.

Similar to what we have for runtime PM callbacks, with pm_runtime_irq_safe().

> >
> > The atomic regulator was a subset of regulator that only handled
> > regulators that would result in something like an atomic register write.
> >
> > In the end it was not worth trying to upstream this approach, and
> > as I remember it, Ulf Hansson intended to let the power domains poke
> > these registers directly, which was easier. (It's on Ulfs TODO list to
> > actually implement this, hehe.)

Yep, unfortunately I never got to the point. However, poking the
registers directly from the genpd provider's on/off callbacks has
never been my plan.

Instead I would rather expect us to call into a Ux500 specific
interface for the prcmu FW. Simply because it's not really a regulator
and must not be modelled like it. Instead it is a voltage/frequency
domain that is managed behind a FW interface.

> >
> > Yours,
> > Linus Walleij
>
> Thanks for all the feedback.
>
> The approach taken with the patchset seems to be architecturally wrong
> and as Linus pointed out has additionally the flaw that the regulator
> would need to be controllable in atomic context which depending on
> the regulator driver / configuration may not be fulfilled.

See above. Perhaps GENPD_FLAG_IRQ_SAFE and pm_runtime_irq_safe() can
help with this?

Note that, power domains can be modelled with child/parents too, which
perhaps can help around this too.

>
> So our plan is to explicitly handle a (shared) regulator in every
> driver involved, adding that regulator capability for drivers not
> already having one.

Please don't! I have recently rejected a similar approach for Tegra
platforms, which now have been converted into using the power domain
approach.

If it's a powerail that is shared between controllers (devices), used
to keep their registers values for example, that should be modelled as
a power domain. Moreover for power domains, we can support
voltage/frequency (performance) scaling, which isn't really applicable
to a plain regulator.

However, if the actual powerrail fits well to be modelled as
regulator, please go ahead. Although, in this case, the regulator must
only be controlled behind a genpd provider's on/off callback, so you
still need the power domain approach, rather than using the regulator
in each driver and for each device.

>
>
> The question which remains is on how one would model functionality
> which by itself does not need a driver but would need regulator
> support to switch its supply on in run state and off in suspend
> states and poweroff, like for example a simple level shifter.

Not sure I understand the question properly, but perhaps by adopting
my proposal above this problem becomes easier to solve?

> Any suggestions on this topic? Thanks.
>
> Cheers
> Max

Kind regards
Uffe