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: <20180822095327.GA21659@localhost.localdomain>
Date:   Wed, 22 Aug 2018 12:53:27 +0300
From:   Matti Vaittinen <matti.vaittinen@...rohmeurope.com>
To:     lgirdwood@...il.com, broonie@...nel.org, mazziesaccount@...il.com
Cc:     mikko.mutanen@...rohmeurope.com, heikki.haikola@...rohmeurope.com,
        matti.vaittinen@...rohmeurope.com, linux-kernel@...r.kernel.org
Subject: [PATCH] regulator: regmap helpers - support overlapping linear ranges

Don't give up voltage mapping if first range with suitable min/max uV
does not provide the wanted voltage.

Signed-off-by: Matti Vaittinen <matti.vaittinen@...rohmeurope.com>
---

We may have HW which handles regulator voltage setting like:
LDO5 voltage reg:
bit [3] voltage range selection
bit [2:0] voltage selection where:

If D[3]=0,

000 = 0.7V
001 = 0.8V
010 = 0.9V
011 = 1.0V
100 = 1.1V
101 = 1.2V
110 = 1.3V
111 = 1.4V

If D[3]=1,

000 = 0.675V
001 = 0.775V
010 = 0.875V
011 = 0.975V
100 = 1.075V
101 = 1.175V
110 = 1.275V
111 = 1.375V

which can be described as:

REGULATOR_LINEAR_VOLTAGE(700000, 0x0, 0x7, 100000)
REGULATOR_LINEAR_VOLTAGE(675000, 0x8, 0xF, 100000)

If consumer wants to use exactly 775000 uV current implementation of
regulator_map_voltage_linear_range will pick up first range (as 775000
is between min uV and max uV for this range) and fail because first
range is not supporting this voltage. This change makes
regulator_map_voltage_linear_range to continue checking rest of the
ranges if they support requested voltage before failing out.

Unfortunately this approach only works if 'range selection bit' follows
immediately after voltage selection bits - which is not case for
ROHM BD71837/BD71847 PMICs. Hence I will soon submit patch with helpers
supporting 'pickable range' register - which would solve also this
issue. Yet, the 'pickable range' solution is not as elegant as current
linear range solution is (in my opinion) - hence I suggest this addition
for cases where we have contagious vsel mask but overlapping linear
ranges.

 drivers/regulator/helpers.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/regulator/helpers.c b/drivers/regulator/helpers.c
index 2ae7c3ac5940..ef09021dc46e 100644
--- a/drivers/regulator/helpers.c
+++ b/drivers/regulator/helpers.c
@@ -321,17 +321,18 @@ int regulator_map_voltage_linear_range(struct regulator_dev *rdev,
 
 		ret += range->min_sel;
 
-		break;
+		/*
+		 * Map back into a voltage to verify we're still in bounds.
+		 * If we are not, then continue checking rest of the ranges.
+		 */
+		voltage = rdev->desc->ops->list_voltage(rdev, ret);
+		if (voltage >= min_uV && voltage <= max_uV)
+			break;
 	}
 
 	if (i == rdev->desc->n_linear_ranges)
 		return -EINVAL;
 
-	/* Map back into a voltage to verify we're still in bounds */
-	voltage = rdev->desc->ops->list_voltage(rdev, ret);
-	if (voltage < min_uV || voltage > max_uV)
-		return -EINVAL;
-
 	return ret;
 }
 EXPORT_SYMBOL_GPL(regulator_map_voltage_linear_range);
-- 
2.14.3

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ