BMC/Intel-BMC/linux.git/drivers/regulator/core.c, branch dev-4.4

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

Merge remote-tracking branches 'regulator/topic/supply', 'regulator/topic/tps6105x' and 'regulator/topic/tps65023' into regulator-next

2015-11-04T11:19:43+00:00

Merge remote-tracking branch 'regulator/topic/list' into regulator-next

2015-11-04T11:19:36+00:00

Merge remote-tracking branch 'regulator/topic/core' into regulator-next

2015-11-04T11:19:36+00:00

regulator: Use regulator_lock_supply() for get_voltage() too

2015-11-04T10:16:05+00:00

Since we need to read voltages of parents as part of setting supply voltages we need to be able to do get_voltage() internally without taking locks so reorganize the locking to take locks on the full tree on entry rather than as we recurse when called externally. Reported-by: John Stultz Tested-by: John Stultz Signed-off-by: Mark Brown