linux-kernel - Re: [PATCH v4 3/4] regulator: Add support for a fixed delay after voltage increases

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:   Thu, 15 Sep 2016 20:51:41 +0800
From:   Doug Anderson <dianders@...omium.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Matthias Kaehlcke <mka@...omium.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Brian Norris <briannorris@...omium.org>,
        Javier Martinez Canillas <javier@...hile0.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v4 3/4] regulator: Add support for a fixed delay after
 voltage increases

Hi

On Tue, Sep 13, 2016 at 2:36 AM, Mark Brown <broonie@...nel.org> wrote:
> On Tue, Sep 06, 2016 at 12:05:04PM -0700, Matthias Kaehlcke wrote:
>
>> the stabilisation time. This change introduces the device tree property
>> "regulator-settle-time-up-us" which allows to specify a fixed delay
>
>> We don't add an option of a fixed delay on the way down for now because
>> the way down is probably modelled best with a ramp rate, not a fixed
>> delay.
>
> Are you sure?  It seems more likely to be highly load dependent if
> there's an appreciable variation.  That could be a ramp rate if you've
> got a very predictable load and a simple regulator but it seems like
> the system is less likely to care if we collapsed down in that case.

In the particular case we cared about we had to make some assumptions
about the slowest possible ramp rate downward because we were trying
to avoid triggering an over voltage protection.  In that particular
case the best way to model it was with a ramp rate because longer
voltage changes caused longer worst case transitions.  Just like you
said, the actual ramp time is highly variable but the "worst case
slowest" ramp time is best modeled with a ramp rate.

-Doug