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, 19 Jun 2013 23:38:28 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Nishanth Menon <nm@...com>
Cc:	Liam Girdwood <lgirdwood@...il.com>, linux-kernel@...r.kernel.org,
	linux-omap@...r.kernel.org
Subject: Re: [RFC PATCH] regulator: core: allow consumers to request to
 closes step voltage

On Wed, Jun 19, 2013 at 02:17:54PM -0500, Nishanth Menon wrote:

> Account for step size accuracy when exact voltage requests are send for
> step based regulators.

If the consumer can tolerate a different voltage why not just request
the range that can be tolerated?  Your problem here is specifying an
exact voltage.

> The specific example I faced was using cpufreq-cpu0 driver with voltages
> for OPPs for MPU rail and attempting the common definitions against voltages
> that are non-exact multiples of stepsize of PMIC.

> The alternative would be implement custom set_voltage (as againsta simpler
> set_voltage_sel and using linear map/list functions) for the regulator which
> will account for the same.

> Yet another alternative might be to introduce yet another custom function similar
> to regulator_set_voltage_tol which accounts for this. something like:
> regulator_set_voltage_floor(regulator, voltage, tol) or something to that effect.

Or as I keep telling you guys the consumer can just do that directly
using the existing API; the whole point in specifying the voltage as a
range is to allow the consumer to cope with arbatrary regulators by
giving a range of voltages that it can accept.

The API is deliberately very conservative in these matters since there
is a danger of physical damage if things really go wrong in some
applications, it makes sure that both the drivers and the system
integration are involved.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ