linux-kernel - Re: [PATCH V2] regulator: core: add support for configuring turn-on time through constraints

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] [day] [month] [year] [list]

Message-ID: <20130912101229.GD29403@sirena.org.uk>
Date:	Thu, 12 Sep 2013 11:12:29 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Laxman Dewangan <ldewangan@...dia.com>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"mark.rutland@....com" <mark.rutland@....com>,
	"rob@...dley.net" <rob@...dley.net>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"lgirdwood@...il.com" <lgirdwood@...il.com>
Subject: Re: [PATCH V2] regulator: core: add support for configuring turn-on
 time through constraints

On Wed, Sep 11, 2013 at 11:59:48AM -0600, Stephen Warren wrote:
> On 09/11/2013 12:09 PM, Laxman Dewangan wrote:

> >> I suppose that either is fine from a DT perspective. But, the regulator
> >> drivers already know their internal delay, so presumably driver code
> >> will have to take the value from DT, and subtract out whatever delay the
> >> driver already embodies, in order to calculate the extra delay required?
> >> Or, if this property is set, does the driver-specified delay just get
> >> ignored?

> > Yes, if property is available then driver-specified delay get ignored.
> > Delay will be used from dt provided value.

> I'm not sure whether I prefer one option or the other. Perhaps Mark can
> decide?

The drivers don't implement their own delays, this is already factored
out of them into the framework.  It seems simpler from both a user and
implementation point of view for the delay specified in the DT to just
completely override what the drivers know.

> That said, what if the internal ramp rate of the regulator itself is
> configurable, and can change at run-time. Won't that affect the total
> time? If so, having this property represent the additional time might
> better allow the total time to be recalculated based on internal
> regulator ramp delay changes. Perhaps the additional time varies if the
> internal ramp rate varies though, so perhaps it's not worth thinking
> about this situation.

There's very little use case for varying the ramp rate from cold at run
time - it's mostly just used to limit inrush current on initial power
on.  I think it's OK to just say that if someone specifies a fixed dleay
and varies the ramp rate then they probably aren't being sensible and
get to keep all the pieces.

> - regulator-enable-ramp-delay: The time taken, in uSec, for the supply

microseconds.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)