It is possible for _regulator_do_enable() to be called for an
already-enabled rdev, like in regulator_suspend_finish(). If we were
using an enable pin (rdev->ena_pin is set) then we'd end up
incrementing the reference count in regulator_ena_gpio_ctrl() over and
over again without a decrement. That prevented the GPIO from going to
the "off" state even after all users were disabled.
Fix this by avoiding the call to regulator_ena_gpio_ctrl() when it's
not needed.
Signed-off-by: Doug Anderson <dianders@xxxxxxxxxxxx>
Fixes: 967cfb18c0e3 ("regulator: core: manage enable GPIO list")
---
FYI: this was developed and tested against a 3.14 kernel with
backports; I've done basic boot testing against upstream and sanity
checked the code but haven't done as extensive testing there.
drivers/regulator/core.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index b899947..9daccbb 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1839,10 +1839,12 @@ static int _regulator_do_enable(struct regulator_dev *rdev)
}
if (rdev->ena_pin) {
- ret = regulator_ena_gpio_ctrl(rdev, true);
- if (ret < 0)
- return ret;
- rdev->ena_gpio_state = 1;
+ if (!rdev->ena_gpio_state) {
+ ret = regulator_ena_gpio_ctrl(rdev, true);
+ if (ret < 0)
+ return ret;
+ rdev->ena_gpio_state = 1;
+ }
} else if (rdev->desc->ops->enable) {
ret = rdev->desc->ops->enable(rdev);
if (ret < 0)
@@ -1939,10 +1941,12 @@ static int _regulator_do_disable(struct regulator_dev *rdev)
trace_regulator_disable(rdev_get_name(rdev));
if (rdev->ena_pin) {
- ret = regulator_ena_gpio_ctrl(rdev, false);
- if (ret < 0)
- return ret;
- rdev->ena_gpio_state = 0;
+ if (rdev->ena_gpio_state) {
+ ret = regulator_ena_gpio_ctrl(rdev, false);
+ if (ret < 0)
+ return ret;
+ rdev->ena_gpio_state = 0;
+ }
} else if (rdev->desc->ops->disable) {
ret = rdev->desc->ops->disable(rdev);
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html