linux-kernel - Re: [RFC PATCH v2 01/17] OPP: Allow to request stub voltage regulators

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]

Date:   Wed, 24 Oct 2018 12:11:23 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Dmitry Osipenko <digetx@...il.com>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Rob Herring <robh+dt@...nel.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Nishanth Menon <nm@...com>, Stephen Boyd <sboyd@...nel.org>,
        Marcel Ziswiler <marcel.ziswiler@...adex.com>,
        linux-tegra@...r.kernel.org, linux-pm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2 01/17] OPP: Allow to request stub voltage
 regulators

On 22-10-18, 15:12, Dmitry Osipenko wrote:
> Because there is one Tegra20 board (tegra20-trimslice) that doesn't declare
> necessary regulators, but we want to have CPU frequency scaling. I couldn't
> find board schematics and so don't know if CPU / CORE voltages are fixed on
> Trim-Slice or it is just preferable not to have DVFS for that board, it is an
> outlet-powered device [0]. Hence tegra20-cpufreq driver will request a dummy
> regulators when appropriate. 

We have been using the regulator_get_optional() variant until now in the OPP
core to make sure that we don't do DVFS for the CPU without the mandatory
regulators being present, as that may make things unstable and cause harm to the
SoC if we try to take CPU to frequency range over the currently programmed
regulator can support.

Now coming back to tegra-20 SoC, which actually requires a regulator normally by
design. On one of the boards (which is outlet powered), you aren't sure if there
is a programmable regulator or not, or if DVFS should really be done or not.
Isn't it worth checking the same from Tegra maintainers, or whomsoever has
information on that board ? What would happen if there actually was a regulator
and its default settings aren't good enough for high end frequencies ?

On the other hand, the tegra20 cpufreq driver is common across a lot of boards.
What will happen if the DT for some of the boards isn't correct and missed the
necessary regulator node ? And because you are moving to regulator_get() API for
the entire SoC (i.e. its cpufreq driver), people will never find the missing
regulator.

If we can do it safely for all tegra20 boards, why not migrate to using
regulator_get() instead of regulator_get_optional() in the OPP core API itself
for everyone ?

-- 
viresh