kernel/linux.git/drivers/regulator/core.c, branch v4.11.5

Merge remote-tracking branches 'regulator/topic/s2mpa01', 'regulator/topic/supplies' and 'regulator/topic/tps65217' into regulator-next

2017-02-19T16:40:41+00:00

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

2017-02-19T16:40:23+00:00

Merge remote-tracking branches 'regulator/fix/debugfs' and 'regulator/fix/tps65086' into regulator-linus

2017-02-19T16:40:22+00:00

regulator: core: Resolve supplies before disabling unused regulators

2017-02-16T18:15:01+00:00

After commit 66d228a2bf03 ("regulator: core: Don't use regulators as supplies until the parent is bound"), input supplies aren't resolved if the input supplies parent device has not been bound. This prevent regulators to hold an invalid reference if its supply parent device driver probe is deferred. But this causes issues on some boards where a PMIC's regulator use as input supply a regulator from another PMIC whose driver is registered after the driver for the former. In this case the regulators for the first PMIC will fail to resolve input supplies on regulators registration (since the other PMIC wasn't probed yet). And when the core attempts to resolve again latter when the other PMIC registers its own regulators, it will fail again since the parent device isn't bound yet. This will cause some parent supplies to never be resolved and wrongly be disabled on boot due taking them as unused. To solve this problem, also attempt to resolve the pending regulators input supplies before disabling the unused regulators. Signed-off-by: Javier Martinez Canillas Signed-off-by: Mark Brown

regulator: Fix regulator_summary for deviceless consumers

2017-02-16T12:44:58+00:00

It is allowed to call regulator_get with a NULL dev argument (_regulator_get explicitly checks for it) but this causes an error later when printing /sys/kernel/debug/regulator_summary. Fix this by explicitly handling "deviceless" consumers in the debugfs code. Signed-off-by: Leonard Crestez Signed-off-by: Mark Brown Cc: stable@vger.kernel.org

regulator: core: simplify _regulator_get()

2017-02-08T18:29:05+00:00

The code in _regulator_get() got a bit confusing over time, with control flow jumping to a label from couple of places. Let's untangle it a bit by doing the following: 1. Make handling of missing supplies and substituting them with dummy regulators more explicit: - check if we not have full constraints and refuse considering dummy regulators with appropriate message; - use "switch (get_type)" to handle different types of request explicitly as well. "Normal" requests will get dummies, exclusive will not and will notify user about that; optional will fail silently. 2. Stop jumping to a label in the middle of the function but instead have proper conditional flow. I believe jumps should be reserved for error handling, breaking from inner loop, or restarting a loop, but not for implementing normal conditional flow. Signed-off-by: Dmitry Torokhov Signed-off-by: Mark Brown

regulator: core: have regulator_dev_lookup() return ERR_PTR-encoded errors

2017-02-05T16:36:40+00:00

Instead of returning both regulator_dev structure as return value and auxiliary error code in 'ret' argument, let's switch to using ERR_PTR encoded values. This makes it more obvious what is going on at call sites. Also, let's not unlock the mutex in the middle of a loop, but rather break out and have single unlock path. Signed-off-by: Dmitry Torokhov Signed-off-by: Mark Brown

regulator: core: fix typo in regulator_bulk_disable()

2017-02-04T10:37:32+00:00

"re-enable" was misspelled as "reename". Signed-off-by: Dmitry Torokhov Signed-off-by: Mark Brown

regulator: core: simplify regulator_bulk_force_disable()

2017-02-04T10:37:24+00:00

There is no need to have two loops there, we can store error for subsequent reporting. Signed-off-by: Dmitry Torokhov Signed-off-by: Mark Brown

regulator: core: have _regulator_get() accept get_type argument

2017-02-04T10:31:52+00:00

Instead of separate "exclusive" and "allow_dummy" arguments, that formed 3 valid combinations (normal, exclusive and optional) and an invalid one, let's accept explicit "get_type", like we did in devm-managed code. Signed-off-by: Dmitry Torokhov Signed-off-by: Mark Brown