linux-kernel - Re: [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override

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]

Date:   Fri, 5 May 2017 09:18:37 +0800
From:   Shawn Guo <shawnguo@...nel.org>
To:     Marek Vasut <marex@...x.de>
Cc:     Leonard Crestez <leonard.crestez@....com>,
        Peter Chen <Peter.Chen@....com>,
        Anson Huang <Anson.Huang@....com>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Sascha Hauer <kernel@...gutronix.de>,
        Fabio Estevam <fabio.estevam@....com>,
        Fabio Estevam <festevam@...il.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override

On Thu, May 04, 2017 at 04:34:14PM +0200, Marek Vasut wrote:
> On 05/04/2017 03:41 PM, Shawn Guo wrote:
> > So I guess you do not understand how the OPP hackery was born and why it
> > shouldn't be there for mainline kernel at all.
> 
> The OPP hackery is there to keep both regulators configured the same
> way, since they share the same input voltage rail IMO.

Yes.  But configuring both regulators the same way is only required in
vendor kernel where 'LDO bypass' mode is used.  With 'LDO enable' mode
which is the case for upstream kernel, both regulators can be configured
differently even they share the same input rail.

> If you model the
> power distribution correctly, the OPP hackery can be removed.

The OPP hackery can be removed even without reg_arm/reg_soc modeling.
That's why we can do hackery dropping and reg_arm/reg_soc modeling in
separate patches.

@Leonard, if someday we support 'LDO bypass' mode in upstream kernel,
the OPP hackery needs to be back in some way even with reg_arm/reg_soc
modeling in place, right?  Or will we have a better way to ensure SW1A
rail can always feed a correct voltage directly to reg_arm&reg_soc?

Shawn