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  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 <>
To:     Dmitry Osipenko <>
Cc:     "Rafael J. Wysocki" <>,
        Rob Herring <>,
        Thierry Reding <>,
        Jonathan Hunter <>,
        Nishanth Menon <>, Stephen Boyd <>,
        Marcel Ziswiler <>,,,,
Subject: Re: [RFC PATCH v2 01/17] OPP: Allow to request stub voltage

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

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 ?


Powered by blists - more mailing lists