linux-kernel - Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based on platform behavior

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

Date:	Wed, 13 Apr 2016 07:53:10 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Laxman Dewangan <ldewangan@...dia.com>
Cc:	Bjorn Andersson <bjorn@...o.se>,
	Bjorn Andersson <bjorn.andersson@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Liam Girdwood <lgirdwood@...il.com>,
	Stephen Warren <swarren@...dotorg.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Gandhar Dighe <gdighe@...dia.com>,
	Stuart Yates <syates@...dia.com>
Subject: Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based
 on platform behavior

On Tue, Apr 12, 2016 at 06:59:06PM +0530, Laxman Dewangan wrote:

> I have put my understanding based on datasheet and observation but it seems
> I am missing some important information which is making difficult to
> understand further here.
> We are not crossing the maximum limit of the load on the rail per datasheet.
> We just changed the output capacitor in the platforms and saw deviation.

Well, we might be hitting an inrush limit as we attempt to ramp the
voltage up.

> I think I need to go again to Vendor to find out that why changing of
> capacitor making the deviation in ramp delay and what is the relation.
> Probably, that may help here.

Possibly.  It did also occur to me last night that having a Maxim
specific property which lets you specify a raw register value to
configure in cases where the board goes out of spec (as opposed to a
time which could be left specified as the real value) might solve the
problem without being too terrible from an interface point of view,
though something that's directly obvious from the schematic would be
much better.

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