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]

Message-ID: <20160628195337.GC17217@sirena.org.uk>
Date:	Tue, 28 Jun 2016 20:53:37 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Doug Anderson <dianders@...omium.org>
Cc:	Boris Brezillon <boris.brezillon@...e-electrons.com>,
	Lee Jones <lee.jones@...aro.org>,
	Brian Norris <briannorris@...omium.org>,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
	Heiko Stuebner <heiko@...ech.de>,
	Liam Girdwood <lgirdwood@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] regulator: pwm: Fix regulator ramp delay for continuous
 mode

On Tue, Jun 28, 2016 at 12:31:19PM -0700, Doug Anderson wrote:

> In all seriousness, I think the design for usleep_range() is to try to
> batch up wakeups to allow longer periods of sleeping and to optimize
> power.  This you want to sleep as long as is allowable and then if you
> happen to wakeup for some other reason anyway then you process all the
> things whose minimum has passed.  IIRC it was trying to get back to
> the good old days of only having jiffies where everyone was
> synchronized on the tick and you could sleep till the next tick after
> all the work was done.  When you think of it this way then sleeping to
> the max makes sense.  ...but it also means that you need to be careful
> and really not set the max too high.

That's what I *thought* it was doing, but when I looked at the
implementation down to the hrtimer level it was explicitly saying it was
actively trying to deliver the maximum delay but might do less.  I'd
have expected that the implementation would check to see if there was a
wakeup scheduled in the range, piggybacking on the first one if so, and 
if there was nothing it'd go for the minimum (perhaps with a bit of
rounding).  Oh well.

> Of course, in practice I've found that often usleep_range() 99% of the
> time sleeps for the max.  That can lead to some very subtle bugs if
> your min sleep is not long enough (!).

Yup.

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