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] [day] [month] [year] [list]
Message-ID: <20170227185310.GA153648@google.com>
Date:   Mon, 27 Feb 2017 10:53:10 -0800
From:   Matthias Kaehlcke <mka@...omium.org>
To:     Rob Herring <robh@...nel.org>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        Douglas Anderson <dianders@...omium.org>,
        Brian Norris <briannorris@...omium.org>,
        Guenter Roeck <groeck@...omium.org>,
        Dmitry Torokhov <dtor@...omium.org>
Subject: Re: [PATCH v1] regulator: Add driver for voltage controlled
 regulators

El Fri, Feb 24, 2017 at 07:19:19PM -0800 Matthias Kaehlcke ha dit:

> El Tue, Feb 21, 2017 at 06:22:14PM -0600 Rob Herring ha dit:
> >
> > > +Optional properties:
> > > +--------------------
> > > ...
> > > +- min-slew-down-rate	: Describes how slowly the regulator voltage will decay
> > > +			  down in the worst case (lightest expected load).
> > > +			  Specified in uV / us (like main regulator ramp rate).
> > > +			  This value is required when ovp-threshold-percent is
> > > +			  specified.
> > 
> > Don't we have a standard prop for this or that's just for ramp?
> 
> regulator-ramp-delay is related, but not exactly the same. The
> ramp-delay is applied at the end of an up- or downward transition,
> while this prop only specifies the downward rate and is applied in
> between partial transitions towards the final voltage.
> 
> We possibly could use ramp-delay and add a set_voltage_time() op to
> vctrl to prevent the core code from adding the "normal" ramp-delay at
> the end of the transition. However it could be confusing that vctrl
> handles the ramp-delay differently than other drivers, especially we
> don't want a delay in the upward transition for vctrl. But maybe
> nobody would care about the different behavior, as long as the
> regulator does its job ...

Actually the behavior of a delay on the downward transition and no
delay on the upward transition is hardware specific. Other users of
this driver might need a standard ramp delay, therefore I think it's
not a good idea to (re-)use this property in vctrl.

Matthias

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ