linux-kernel - Re: [PATCH] regulator: Support ramp-up delay for drivers with get

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

Message-ID: <20160330203946.GT2350@sirena.org.uk>
Date:	Wed, 30 Mar 2016 13:39:46 -0700
From:	Mark Brown <broonie@...nel.org>
To:	Stephen Boyd <stephen.boyd@...aro.org>
Cc:	Georgi Djakov <georgi.djakov@...aro.org>,
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH] regulator: Support ramp-up delay for drivers with
 get_voltage()

On Wed, Mar 30, 2016 at 12:34:26PM -0700, Stephen Boyd wrote:

> Ok. Just curious, why is there a 'selector' argument to the
> set_voltage() op then? The qcom spmi driver is using that to allow the
> list operation to return the voltage that was actually set. Is that a
> 'selector' interface? We could just as easily have read the hardware to
> figure out the voltage, but I think we implement the list op to avoid
> reading hardware when we know what selector has been chosen during
> voltage changes.

Historical reasons - this predates having the split selector and map
operations.

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