linux-kernel - Re: [PATCH] regulator: pwm: Fix regulator ramp delay for continuous mode

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:	Tue, 28 Jun 2016 19:52:44 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Douglas Anderson <dianders@...omium.org>
Cc:	boris.brezillon@...e-electrons.com, lee.jones@...aro.org,
	briannorris@...omium.org, linux-rockchip@...ts.infradead.org,
	Heiko Stuebner <heiko@...ech.de>, lgirdwood@...il.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] regulator: pwm: Fix regulator ramp delay for continuous
 mode

On Mon, Jun 27, 2016 at 09:53:11PM -0700, Douglas Anderson wrote:

> Note also that the upper bound of usleep_range probably shouldn't be a
> full 1 ms longer than the lower bound since I've seen plenty of hardware
> with a ramp rate of ~5000 uS / uV and for small jumps the total delays
> are in the tens of uS.  1000 is way too much.  We'll try to be dynamic
> and use 10%

Surely the upper bound here is just an upper bound and we're essentially
just saying that "anything over minimum is fine" here?  Though now I
look at the implementation it seems it's doing something entirely
unehelpful and actually trying to delay for the longest possible time
which doesn't seem like what we want or what the usleep_range() API
would suggest :(

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