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: <CAPDyKFow5yxgCa-PTpNsiHzr3kCPCcOn-FVWdHCG9dx54cS=pA@mail.gmail.com>
Date:   Wed, 15 Jun 2022 14:14:27 -0700
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Max Krummenacher <max.oss.09@...il.com>
Cc:     max.krummenacher@...adex.com, 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>, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 0/5] power: domain: Add driver for a PM domain provider
 which controls

On Thu, 9 Jun 2022 at 08:09, Max Krummenacher <max.oss.09@...il.com> wrote:
>
> From: Max Krummenacher <max.krummenacher@...adex.com>
>
> its power enable by using a regulator.
>
> The currently implemented PM domain providers are all specific to
> a particular system on chip.
>
> This series adds a PM domain provider driver which enables/disables
> a regulator to control its power state. Additionally, marked with RFC,
> it adds two commits which actually make use of the new driver to
> instantiate a power domain provider and have a number of power
> domain consumers use the power domain.
>
> The perceived use case is to control a common power domain used by
> several devices for which not all device drivers nessesarily have
> a means to control a regulator.
>
> It also handles the suspend / resume use case for such devices,
> the generic power domain framework will disable the domain once the
> last device has been suspend and will enable it again before resuming
> the first device.
>
> The generic power domain code handles a power domain consumer
> generically outside of the driver's code. (assuming the 'power-domains'
> property references exactly one power domain).
> This allows to use the "regulator-pm-pd" driver with an arbitrary
> device just by adding the 'power-domains' property to the devices
> device tree node. However the device's dt-bindings schema likely does
> not allow the property 'power-domains'.
> One way to solve this would be to allow 'power-domains' globally
> similarly how 'status' and other common properties are allowed as
> implicit properties.

I don't want to interrupt the discussion, but I still wanted to share
my overall thoughts around the suggested approach.

Rather than adding some new DT bindings and a new generic DT
compatible, I think the current power-domains bindings are sufficient
to describe these types of HWs.

To me, it looks rather like you are striving towards avoiding open
coding for power domain providers that make use of a regulator. Right?

To address that problem, I think a better option is to consider
introducing a helper library with a set of functions that can be used
by these types of power domain providers, in a way to simplify the
code.

[...]

Kind regards
Uffe