linux-stable.git/drivers/regulator, branch v4.4.16

regulator: axp20x: Fix axp22x ldo_io voltage ranges

2016-05-19T00:06:51+00:00

commit a2262e5a12e05389ab4c7fc5cf60016b041dd8dc upstream.

The minium voltage of 1800mV is a copy and paste error from the axp20x
regulator info. The correct minimum voltage for the ldo_io regulators
on the axp22x is 700mV.

Fixes: 1b82b4e4f954 ("regulator: axp20x: Add support for AXP22X regulators")
Signed-off-by: Hans de Goede 
Acked-by: Chen-Yu Tsai 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regulator: s2mps11: Fix invalid selector mask and voltages for buck9

2016-05-19T00:06:51+00:00

commit 3b672623079bb3e5685b8549e514f2dfaa564406 upstream.

The buck9 regulator of S2MPS11 PMIC had incorrect vsel_mask (0xff
instead of 0x1f) thus reading entire register as buck9's voltage. This
effectively caused regulator core to interpret values as higher voltages
than they were and then to set real voltage much lower than intended.

The buck9 provides power to other regulators, including LDO13
and LDO19 which supply the MMC2 (SD card). On Odroid XU3/XU4 the lower
voltage caused SD card detection errors on Odroid XU3/XU4:
	mmc1: card never left busy state
	mmc1: error -110 whilst initialising SD card

During driver probe the regulator core was checking whether initial
voltage matches the constraints. With incorrect vsel_mask of 0xff and
default value of 0x50, the core interpreted this as 5 V which is outside
of constraints (3-3.775 V). Then the regulator core was adjusting the
voltage to match the constraints. With incorrect vsel_mask this new
voltage mapped to a vere low voltage in the driver.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regulator: s5m8767: fix get_register() error handling

2016-05-04T21:48:50+00:00

commit e07ff9434167981c993a26d2edbbcb8e13801dbb upstream.

The s5m8767_pmic_probe() function calls s5m8767_get_register() to
read data without checking the return code, which produces a compile-time
warning when that data is accessed:

drivers/regulator/s5m8767.c: In function 's5m8767_pmic_probe':
drivers/regulator/s5m8767.c:924:7: error: 'enable_reg' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/regulator/s5m8767.c:944:30: error: 'enable_val' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This changes the s5m8767_get_register() function to return a -EINVAL
not just for an invalid register number but also for an invalid
regulator number, as both would result in returning uninitialized
data. The s5m8767_pmic_probe() function is then changed accordingly
to fail on a read error, as all the other callers of s5m8767_get_register()
already do.

In practice this probably cannot happen, as we don't call
s5m8767_get_register() with invalid arguments, but the gcc
warning seems valid in principle, in terms writing safe
error checking.

Signed-off-by: Arnd Bergmann 
Fixes: 9c4c60554acf ("regulator: s5m8767: Convert to use regulator_[enable|disable|is_enabled]_regmap")
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regulator: core: Fix nested locking of supplies

2016-05-04T21:48:50+00:00

commit 70a7fb80e85ae7f78f8e90cec3fbd862ea6a4d4b upstream.

Commit fa731ac7ea04 ("regulator: core: avoid unused variable warning")
introduced a subtle change in how supplies are locked. Where previously
code was always locking the regulator of the current iteration, the new
implementation only locks the regulator if it has a supply. For any
given power tree that means that the root will never get locked.

On the other hand the regulator_unlock_supply() will still release all
the locks, which in turn causes the lock debugging code to warn about a
mutex being unlocked which wasn't locked.

Cc: Mark Brown 
Cc: Arnd Bergmann 
Fixes: fa731ac7ea04 ("regulator: core: avoid unused variable warning")
Signed-off-by: Thierry Reding 
Signed-off-by: Mark Brown 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

regulator: core: Ensure we lock all regulators

2016-05-04T21:48:50+00:00

commit 49a6bb7a1c0963f260e4b0dcc2c0e56ec65a28b2 upstream.

The latest workaround for the lockdep interface's not using the second
argument of mutex_lock_nested() changed the loop missed locking the last
regulator due to a thinko with the loop termination condition exiting
one regulator too soon.

Reported-by: Tyler Baker 
Signed-off-by: Mark Brown 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

regulator: core: fix regulator_lock_supply regression

2016-05-04T21:48:50+00:00

commit bb41897e38c53458a88b271f2fbcd905ee1f9584 upstream.

As noticed by Geert Uytterhoeven, my patch to avoid a harmless build warning
in regulator_lock_supply() was total crap and introduced a real bug:

> [ BUG: bad unlock balance detected! ]
> kworker/u4:0/6 is trying to release lock (&rdev->mutex) at:
> [] regulator_set_voltage+0x38/0x50

we still lock the regulator supplies, but not the actual regulators,
so we are missing a lock, and the unlock is unbalanced.

This rectifies it by first locking the regulator device itself before
using the same loop as before to lock its supplies.

Reported-by: Geert Uytterhoeven 
Signed-off-by: Arnd Bergmann 
Fixes: 716fec9d1965 ("[SUBMITTED] regulator: core: avoid unused variable warning")
Signed-off-by: Mark Brown 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

Revert "regulator: core: Fix nested locking of supplies"

2016-05-04T21:48:50+00:00

This reverts commit b1999fa6e8145305a6c8bda30ea20783717708e6 which was
commit 70a7fb80e85ae7f78f8e90cec3fbd862ea6a4d4b upstream.

It causes run-time breakage in the 4.4-stable tree and more patches are
needed to be applied first before this one in order to resolve the
issue.

Reported-by: Guenter Roeck 
Cc: Mark Brown 
Cc: Arnd Bergmann 
Cc: Thierry Reding 
Cc: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regulator: core: Fix nested locking of supplies

2016-04-12T16:08:31+00:00

commit 70a7fb80e85ae7f78f8e90cec3fbd862ea6a4d4b upstream.

Commit fa731ac7ea04 ("regulator: core: avoid unused variable warning")
introduced a subtle change in how supplies are locked. Where previously
code was always locking the regulator of the current iteration, the new
implementation only locks the regulator if it has a supply. For any
given power tree that means that the root will never get locked.

On the other hand the regulator_unlock_supply() will still release all
the locks, which in turn causes the lock debugging code to warn about a
mutex being unlocked which wasn't locked.

Cc: Mark Brown 
Cc: Arnd Bergmann 
Fixes: Fixes: fa731ac7ea04 ("regulator: core: avoid unused variable warning")
Signed-off-by: Thierry Reding 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regulator: core: avoid unused variable warning

2016-04-12T16:08:31+00:00

commit fa731ac7ea04a7d3a5c6d2f568132478c02a83b3 upstream.

The second argument of the mutex_lock_nested() helper is only
evaluated if CONFIG_DEBUG_LOCK_ALLOC is set. Otherwise we
get this build warning for the new regulator_lock_supply
function:

drivers/regulator/core.c: In function 'regulator_lock_supply':
drivers/regulator/core.c:142:6: warning: unused variable 'i' [-Wunused-variable]

To avoid the warning, this restructures the code to make it
both simpler and to move the 'i++' outside of the mutex_lock_nested
call, where it is now always used and the variable is not
flagged as unused.

We had some discussion about changing mutex_lock_nested to an
inline function, which would make the code do the right thing here,
but in the end decided against it, in order to guarantee that
mutex_lock_nested() does not introduced overhead without
CONFIG_DEBUG_LOCK_ALLOC.

Signed-off-by: Arnd Bergmann 
Fixes: 9f01cd4a915 ("regulator: core: introduce function to lock regulators and its supplies")
Link: http://permalink.gmane.org/gmane.linux.kernel/2068900
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regulator: mt6311: MT6311_REGULATOR needs to select REGMAP_I2C

2016-03-03T23:07:17+00:00

commit aab3c3f34cc2dd8230052770712606d65de6538f upstream.

This patch fix the below build error:
drivers/regulator/mt6311-regulator.c:111: undefined reference to `__devm_regmap_init_i2c'

Signed-off-by: Henry Chen 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman