linux-kernel - Re: [RFC PATCH v1 5/5] ARM64: verdin-imx8mm: use regulator power domain to model sleep-moci

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAMuHMdUf=VnqePKB=0eJC4GxZipQLD8BKMiv5PBW8Fz+zUv6-Q@mail.gmail.com>
Date:   Tue, 14 Jun 2022 09:29:33 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Max Krummenacher <max.oss.09@...il.com>
Cc:     Max Krummenacher <max.krummenacher@...adex.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        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>,
        Fabio Estevam <festevam@...il.com>,
        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>,
        "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: [RFC PATCH v1 5/5] ARM64: verdin-imx8mm: use regulator power
 domain to model sleep-moci

Hi Max,

On Thu, Jun 9, 2022 at 5:16 PM Max Krummenacher <max.oss.09@...il.com> wrote:
> From: Max Krummenacher <max.krummenacher@...adex.com>
>
> The Verdin CTRL_SLEEP_MOCI# pin signals the carrier board that the module
> is in sleep and it may switch off unneeded power.
>
> Control this pin with a regulator power domain controller which uses a
> fixed regulator with a gpio enable.
>
> Signed-off-by: Max Krummenacher <max.krummenacher@...adex.com>

Thanks for your patch!

> --- a/arch/arm64/boot/dts/freescale/imx8mm-verdin-dahlia.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin-dahlia.dtsi
> @@ -92,6 +92,7 @@
>
>  /* Verdin PCIE_1 */
>  &pcie0 {
> +       power-domains = <&pd_sleep_moci>;

This overrides "power-domains = <&pgc_pcie>;" from imx8mm.dtsi...

>         status = "okay";
>  };

> --- a/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi
> @@ -53,6 +53,14 @@
>                 };
>         };
>
> +       pd_sleep_moci: power-domain-sleep-moci {
> +               compatible = "regulator-pm-pd";
> +               label = "pd_sleep_moci";
> +               power-domains = <&pgc_pcie>;

... and here you work around that by re-binding <&pgc_pcie>.

I think you:
  1. must not override the power-domains property for pcie0, as
     conceptually, the PCIe bus is still in the on-SoC power
     domain. What if some lanes are connected to devices in
     pd_sleep_moci, but other lanes are not?
  2. should only use pd_sleep_moci for the off-chip devices that
      are actually controlled by the corresponding regulator.

> +               power-supply = <&reg_sleep_moci>;
> +               #power-domain-cells = <0>;
> +       };
> +
>         /* Carrier Board Supplies */
>         reg_1p8v: regulator-1p8v {
>                 compatible = "regulator-fixed";

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds