Re: [PATCH 4/5] regulator: core: Add early supply resolution for a bypassed regulator

2016-04-25 Thread Mark Brown
On Mon, Apr 25, 2016 at 03:44:24PM +0100, Jon Hunter wrote:
> On 22/04/16 14:53, Mark Brown wrote:

> > We need to only *fail* in the bypass case.

> OK. So this is what I have now. Is it weird to return EPROBE_DEFER in 
> _regulator_get_voltage()? If so, I could add a test for bypass in the
> regulator_register().

It should be fine but perhaps print an error saying that it's a bypassed
regulator with no supply?  Deferring for no explicit reason can be
confusing.


signature.asc
Description: PGP signature


Re: [PATCH 4/5] regulator: core: Add early supply resolution for a bypassed regulator

2016-04-25 Thread Mark Brown
On Mon, Apr 25, 2016 at 03:44:24PM +0100, Jon Hunter wrote:
> On 22/04/16 14:53, Mark Brown wrote:

> > We need to only *fail* in the bypass case.

> OK. So this is what I have now. Is it weird to return EPROBE_DEFER in 
> _regulator_get_voltage()? If so, I could add a test for bypass in the
> regulator_register().

It should be fine but perhaps print an error saying that it's a bypassed
regulator with no supply?  Deferring for no explicit reason can be
confusing.


signature.asc
Description: PGP signature


Re: [PATCH 4/5] regulator: core: Add early supply resolution for a bypassed regulator

2016-04-25 Thread Jon Hunter

On 22/04/16 14:53, Mark Brown wrote:
> * PGP Signed by an unknown key
> 
> On Fri, Apr 22, 2016 at 12:26:57PM +0100, Jon Hunter wrote:
> 
>> OK. Sorry if I have misunderstood you here, but this sounds more like
>> Thierry's initial proposal [0] but ignoring the any errors returned (and
>> we need to fix-up the locking in this patch). In the discussion that
> 
> Yes!
> 
>> followed I thought we agreed to only do this for the bypass case [1]. As
>> far as I am concerned either will work, but to confirm we should just
>> always try to resolve the supply early during regulator_register(), correct?
> 
> We need to only *fail* in the bypass case.

OK. So this is what I have now. Is it weird to return EPROBE_DEFER in 
_regulator_get_voltage()? If so, I could add a test for bypass in the
regulator_register().

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 5b46d907e61d..7a6b7f667bcb 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3126,7 +3126,7 @@ static int _regulator_get_voltage(struct regulator_dev 
*rdev)
if (bypassed) {
/* if bypassed the regulator must have a supply */
if (!rdev->supply)
-   return -EINVAL;
+   return -EPROBE_DEFER;
 
return _regulator_get_voltage(rdev->supply->rdev);
}
@@ -3943,8 +3943,6 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
rdev->dev.of_node = of_node_get(config->of_node);
}
 
-   mutex_lock(_list_mutex);
-
mutex_init(>mutex);
rdev->reg_data = config->driver_data;
rdev->owner = regulator_desc->owner;
@@ -3969,7 +3967,9 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
 
if ((config->ena_gpio || config->ena_gpio_initialized) &&
gpio_is_valid(config->ena_gpio)) {
+   mutex_lock(_list_mutex);
ret = regulator_ena_gpio_request(rdev, config);
+   mutex_unlock(_list_mutex);
if (ret != 0) {
rdev_err(rdev, "Failed to request enable GPIO%d: %d\n",
 config->ena_gpio, ret);
@@ -3987,31 +3987,40 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
if (init_data)
constraints = _data->constraints;
 
-   ret = set_machine_constraints(rdev, constraints);
-   if (ret < 0)
-   goto wash;
-
if (init_data && init_data->supply_regulator)
rdev->supply_name = init_data->supply_regulator;
else if (regulator_desc->supply_name)
rdev->supply_name = regulator_desc->supply_name;
 
+   /*
+* Attempt to resolve the regulator supply, if specified,
+* but don't return an error if we fail because we will try
+* to resolve it again later as more regulators are added.
+*/
+   if (regulator_resolve_supply(rdev))
+   rdev_dbg(rdev, "unable to resolve supply\n");
+
+   ret = set_machine_constraints(rdev, constraints);
+   if (ret < 0)
+   goto wash;
+
/* add consumers devices */
if (init_data) {
+   mutex_lock(_list_mutex);
for (i = 0; i < init_data->num_consumer_supplies; i++) {
ret = set_consumer_device_supply(rdev,
init_data->consumer_supplies[i].dev_name,
init_data->consumer_supplies[i].supply);
if (ret < 0) {
+   mutex_unlock(_list_mutex);
dev_err(dev, "Failed to set supply %s\n",
init_data->consumer_supplies[i].supply);
goto unset_supplies;
}
}
+   mutex_unlock(_list_mutex);
}
 
-   mutex_unlock(_list_mutex);
-
ret = device_register(>dev);
if (ret != 0) {
put_device(>dev);
@@ -4028,13 +4037,16 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
return rdev;
 
 unset_supplies:
+   mutex_lock(_list_mutex);
unset_regulator_supplies(rdev);
+   mutex_unlock(_list_mutex);
 wash:
kfree(rdev->constraints);
+   mutex_lock(_list_mutex);
regulator_ena_gpio_free(rdev);
+   mutex_unlock(_list_mutex);
 clean:
kfree(rdev);
-   mutex_unlock(_list_mutex);
kfree(config);
return ERR_PTR(ret);
 }
-- 
2.1.4



Re: [PATCH 4/5] regulator: core: Add early supply resolution for a bypassed regulator

2016-04-25 Thread Jon Hunter

On 22/04/16 14:53, Mark Brown wrote:
> * PGP Signed by an unknown key
> 
> On Fri, Apr 22, 2016 at 12:26:57PM +0100, Jon Hunter wrote:
> 
>> OK. Sorry if I have misunderstood you here, but this sounds more like
>> Thierry's initial proposal [0] but ignoring the any errors returned (and
>> we need to fix-up the locking in this patch). In the discussion that
> 
> Yes!
> 
>> followed I thought we agreed to only do this for the bypass case [1]. As
>> far as I am concerned either will work, but to confirm we should just
>> always try to resolve the supply early during regulator_register(), correct?
> 
> We need to only *fail* in the bypass case.

OK. So this is what I have now. Is it weird to return EPROBE_DEFER in 
_regulator_get_voltage()? If so, I could add a test for bypass in the
regulator_register().

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 5b46d907e61d..7a6b7f667bcb 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3126,7 +3126,7 @@ static int _regulator_get_voltage(struct regulator_dev 
*rdev)
if (bypassed) {
/* if bypassed the regulator must have a supply */
if (!rdev->supply)
-   return -EINVAL;
+   return -EPROBE_DEFER;
 
return _regulator_get_voltage(rdev->supply->rdev);
}
@@ -3943,8 +3943,6 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
rdev->dev.of_node = of_node_get(config->of_node);
}
 
-   mutex_lock(_list_mutex);
-
mutex_init(>mutex);
rdev->reg_data = config->driver_data;
rdev->owner = regulator_desc->owner;
@@ -3969,7 +3967,9 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
 
if ((config->ena_gpio || config->ena_gpio_initialized) &&
gpio_is_valid(config->ena_gpio)) {
+   mutex_lock(_list_mutex);
ret = regulator_ena_gpio_request(rdev, config);
+   mutex_unlock(_list_mutex);
if (ret != 0) {
rdev_err(rdev, "Failed to request enable GPIO%d: %d\n",
 config->ena_gpio, ret);
@@ -3987,31 +3987,40 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
if (init_data)
constraints = _data->constraints;
 
-   ret = set_machine_constraints(rdev, constraints);
-   if (ret < 0)
-   goto wash;
-
if (init_data && init_data->supply_regulator)
rdev->supply_name = init_data->supply_regulator;
else if (regulator_desc->supply_name)
rdev->supply_name = regulator_desc->supply_name;
 
+   /*
+* Attempt to resolve the regulator supply, if specified,
+* but don't return an error if we fail because we will try
+* to resolve it again later as more regulators are added.
+*/
+   if (regulator_resolve_supply(rdev))
+   rdev_dbg(rdev, "unable to resolve supply\n");
+
+   ret = set_machine_constraints(rdev, constraints);
+   if (ret < 0)
+   goto wash;
+
/* add consumers devices */
if (init_data) {
+   mutex_lock(_list_mutex);
for (i = 0; i < init_data->num_consumer_supplies; i++) {
ret = set_consumer_device_supply(rdev,
init_data->consumer_supplies[i].dev_name,
init_data->consumer_supplies[i].supply);
if (ret < 0) {
+   mutex_unlock(_list_mutex);
dev_err(dev, "Failed to set supply %s\n",
init_data->consumer_supplies[i].supply);
goto unset_supplies;
}
}
+   mutex_unlock(_list_mutex);
}
 
-   mutex_unlock(_list_mutex);
-
ret = device_register(>dev);
if (ret != 0) {
put_device(>dev);
@@ -4028,13 +4037,16 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
return rdev;
 
 unset_supplies:
+   mutex_lock(_list_mutex);
unset_regulator_supplies(rdev);
+   mutex_unlock(_list_mutex);
 wash:
kfree(rdev->constraints);
+   mutex_lock(_list_mutex);
regulator_ena_gpio_free(rdev);
+   mutex_unlock(_list_mutex);
 clean:
kfree(rdev);
-   mutex_unlock(_list_mutex);
kfree(config);
return ERR_PTR(ret);
 }
-- 
2.1.4



Re: [PATCH 4/5] regulator: core: Add early supply resolution for a bypassed regulator

2016-04-22 Thread Mark Brown
On Fri, Apr 22, 2016 at 12:26:57PM +0100, Jon Hunter wrote:

> OK. Sorry if I have misunderstood you here, but this sounds more like
> Thierry's initial proposal [0] but ignoring the any errors returned (and
> we need to fix-up the locking in this patch). In the discussion that

Yes!

> followed I thought we agreed to only do this for the bypass case [1]. As
> far as I am concerned either will work, but to confirm we should just
> always try to resolve the supply early during regulator_register(), correct?

We need to only *fail* in the bypass case.


signature.asc
Description: PGP signature


Re: [PATCH 4/5] regulator: core: Add early supply resolution for a bypassed regulator

2016-04-22 Thread Mark Brown
On Fri, Apr 22, 2016 at 12:26:57PM +0100, Jon Hunter wrote:

> OK. Sorry if I have misunderstood you here, but this sounds more like
> Thierry's initial proposal [0] but ignoring the any errors returned (and
> we need to fix-up the locking in this patch). In the discussion that

Yes!

> followed I thought we agreed to only do this for the bypass case [1]. As
> far as I am concerned either will work, but to confirm we should just
> always try to resolve the supply early during regulator_register(), correct?

We need to only *fail* in the bypass case.


signature.asc
Description: PGP signature


Re: [PATCH 4/5] regulator: core: Add early supply resolution for a bypassed regulator

2016-04-22 Thread Jon Hunter

On 22/04/16 11:48, Mark Brown wrote:
> * PGP Signed by an unknown key
> 
> On Thu, Apr 21, 2016 at 05:12:00PM +0100, Jon Hunter wrote:
> 
>> A regulator that is in bypass will fail to be registered because we will
>> attempt to get the voltage of the regulator (ie. it's bypass voltage)
>> before the supply for the regulator has been resolved. Therefore, when
>> getting the voltage for a bypassed regulator, if the supply has not been
>> resolved, then attempt to resolve it. Additionally, move the setup of
>> the regulator's supply name to before the call to
>> set_machine_constraints() so that it can be resolved.
> 
> The basic pattern here makes sense but rather than doing this
> specifically in the case where we have a bypassed supply we didn't 
> resolve yet I think we should instead always try to resolve the supply
> but ignore the error unless we actively need the supply.  I'd be
> surprised if we didn't run into other cases where we need to do this so
> it seems better to try the resolution in one place.

OK. Sorry if I have misunderstood you here, but this sounds more like
Thierry's initial proposal [0] but ignoring the any errors returned (and
we need to fix-up the locking in this patch). In the discussion that
followed I thought we agreed to only do this for the bypass case [1]. As
far as I am concerned either will work, but to confirm we should just
always try to resolve the supply early during regulator_register(), correct?

Cheers
Jon

[0] http://marc.info/?t=14600390781=1=2
[1] http://marc.info/?l=linux-kernel=146038421710211=2  


Re: [PATCH 4/5] regulator: core: Add early supply resolution for a bypassed regulator

2016-04-22 Thread Jon Hunter

On 22/04/16 11:48, Mark Brown wrote:
> * PGP Signed by an unknown key
> 
> On Thu, Apr 21, 2016 at 05:12:00PM +0100, Jon Hunter wrote:
> 
>> A regulator that is in bypass will fail to be registered because we will
>> attempt to get the voltage of the regulator (ie. it's bypass voltage)
>> before the supply for the regulator has been resolved. Therefore, when
>> getting the voltage for a bypassed regulator, if the supply has not been
>> resolved, then attempt to resolve it. Additionally, move the setup of
>> the regulator's supply name to before the call to
>> set_machine_constraints() so that it can be resolved.
> 
> The basic pattern here makes sense but rather than doing this
> specifically in the case where we have a bypassed supply we didn't 
> resolve yet I think we should instead always try to resolve the supply
> but ignore the error unless we actively need the supply.  I'd be
> surprised if we didn't run into other cases where we need to do this so
> it seems better to try the resolution in one place.

OK. Sorry if I have misunderstood you here, but this sounds more like
Thierry's initial proposal [0] but ignoring the any errors returned (and
we need to fix-up the locking in this patch). In the discussion that
followed I thought we agreed to only do this for the bypass case [1]. As
far as I am concerned either will work, but to confirm we should just
always try to resolve the supply early during regulator_register(), correct?

Cheers
Jon

[0] http://marc.info/?t=14600390781=1=2
[1] http://marc.info/?l=linux-kernel=146038421710211=2  


Re: [PATCH 4/5] regulator: core: Add early supply resolution for a bypassed regulator

2016-04-22 Thread Mark Brown
On Thu, Apr 21, 2016 at 05:12:00PM +0100, Jon Hunter wrote:

> A regulator that is in bypass will fail to be registered because we will
> attempt to get the voltage of the regulator (ie. it's bypass voltage)
> before the supply for the regulator has been resolved. Therefore, when
> getting the voltage for a bypassed regulator, if the supply has not been
> resolved, then attempt to resolve it. Additionally, move the setup of
> the regulator's supply name to before the call to
> set_machine_constraints() so that it can be resolved.

The basic pattern here makes sense but rather than doing this
specifically in the case where we have a bypassed supply we didn't 
resolve yet I think we should instead always try to resolve the supply
but ignore the error unless we actively need the supply.  I'd be
surprised if we didn't run into other cases where we need to do this so
it seems better to try the resolution in one place.


signature.asc
Description: PGP signature


Re: [PATCH 4/5] regulator: core: Add early supply resolution for a bypassed regulator

2016-04-22 Thread Mark Brown
On Thu, Apr 21, 2016 at 05:12:00PM +0100, Jon Hunter wrote:

> A regulator that is in bypass will fail to be registered because we will
> attempt to get the voltage of the regulator (ie. it's bypass voltage)
> before the supply for the regulator has been resolved. Therefore, when
> getting the voltage for a bypassed regulator, if the supply has not been
> resolved, then attempt to resolve it. Additionally, move the setup of
> the regulator's supply name to before the call to
> set_machine_constraints() so that it can be resolved.

The basic pattern here makes sense but rather than doing this
specifically in the case where we have a bypassed supply we didn't 
resolve yet I think we should instead always try to resolve the supply
but ignore the error unless we actively need the supply.  I'd be
surprised if we didn't run into other cases where we need to do this so
it seems better to try the resolution in one place.


signature.asc
Description: PGP signature


[PATCH 4/5] regulator: core: Add early supply resolution for a bypassed regulator

2016-04-21 Thread Jon Hunter
The call to set_machine_constraints() in regulator_register(), will
attempt to get the voltage for the regulator.

A regulator that is in bypass will fail to be registered because we will
attempt to get the voltage of the regulator (ie. it's bypass voltage)
before the supply for the regulator has been resolved. Therefore, when
getting the voltage for a bypassed regulator, if the supply has not been
resolved, then attempt to resolve it. Additionally, move the setup of
the regulator's supply name to before the call to
set_machine_constraints() so that it can be resolved.

Please note that regulator_resolve_supply() will call
regulator_dev_lookup() which may acquire the regulator_list_mutex. To
avoid any deadlocks we cannot hold the regulator_list_mutex when calling
regulator_resolve_supply(). Following this change because
set_machine_constraints() may now result in a call to
regulator_resolve_supply() for a bypassed regulator, we can no longer
hold the regulator_list_mutex around this call. To avoid this rather
than holding the lock around a large portion of the registration code,
just hold the lock when aquiring any GPIOs and setting up supplies
because these sections may add entries to the regulator_map_list and
regulator_ena_gpio_list, respectively.

Signed-off-by: Jon Hunter 
---
 drivers/regulator/core.c | 31 ---
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 754f3b4c2218..4f57a1832079 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3127,8 +3127,13 @@ static int _regulator_get_voltage(struct regulator_dev 
*rdev)
return ret;
if (bypassed) {
/* if bypassed the regulator must have a supply */
-   if (!rdev->supply)
-   return -EINVAL;
+   if (!rdev->supply) {
+   ret = regulator_resolve_supply(rdev);
+   if (ret < 0)
+   return ret;
+   if (!rdev->supply)
+   return -EINVAL;
+   }
 
return _regulator_get_voltage(rdev->supply->rdev);
}
@@ -3945,8 +3950,6 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
rdev->dev.of_node = of_node_get(config->of_node);
}
 
-   mutex_lock(_list_mutex);
-
mutex_init(>mutex);
rdev->reg_data = config->driver_data;
rdev->owner = regulator_desc->owner;
@@ -3971,7 +3974,9 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
 
if ((config->ena_gpio || config->ena_gpio_initialized) &&
gpio_is_valid(config->ena_gpio)) {
+   mutex_lock(_list_mutex);
ret = regulator_ena_gpio_request(rdev, config);
+   mutex_unlock(_list_mutex);
if (ret != 0) {
rdev_err(rdev, "Failed to request enable GPIO%d: %d\n",
 config->ena_gpio, ret);
@@ -3989,31 +3994,32 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
if (init_data)
constraints = _data->constraints;
 
-   ret = set_machine_constraints(rdev, constraints);
-   if (ret < 0)
-   goto wash;
-
if (init_data && init_data->supply_regulator)
rdev->supply_name = init_data->supply_regulator;
else if (regulator_desc->supply_name)
rdev->supply_name = regulator_desc->supply_name;
 
+   ret = set_machine_constraints(rdev, constraints);
+   if (ret < 0)
+   goto wash;
+
/* add consumers devices */
if (init_data) {
+   mutex_lock(_list_mutex);
for (i = 0; i < init_data->num_consumer_supplies; i++) {
ret = set_consumer_device_supply(rdev,
init_data->consumer_supplies[i].dev_name,
init_data->consumer_supplies[i].supply);
if (ret < 0) {
+   mutex_unlock(_list_mutex);
dev_err(dev, "Failed to set supply %s\n",
init_data->consumer_supplies[i].supply);
goto unset_supplies;
}
}
+   mutex_unlock(_list_mutex);
}
 
-   mutex_unlock(_list_mutex);
-
ret = device_register(>dev);
if (ret != 0) {
put_device(>dev);
@@ -4030,13 +4036,16 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
return rdev;
 
 unset_supplies:
+   mutex_lock(_list_mutex);
unset_regulator_supplies(rdev);
+   mutex_unlock(_list_mutex);
 wash:

[PATCH 4/5] regulator: core: Add early supply resolution for a bypassed regulator

2016-04-21 Thread Jon Hunter
The call to set_machine_constraints() in regulator_register(), will
attempt to get the voltage for the regulator.

A regulator that is in bypass will fail to be registered because we will
attempt to get the voltage of the regulator (ie. it's bypass voltage)
before the supply for the regulator has been resolved. Therefore, when
getting the voltage for a bypassed regulator, if the supply has not been
resolved, then attempt to resolve it. Additionally, move the setup of
the regulator's supply name to before the call to
set_machine_constraints() so that it can be resolved.

Please note that regulator_resolve_supply() will call
regulator_dev_lookup() which may acquire the regulator_list_mutex. To
avoid any deadlocks we cannot hold the regulator_list_mutex when calling
regulator_resolve_supply(). Following this change because
set_machine_constraints() may now result in a call to
regulator_resolve_supply() for a bypassed regulator, we can no longer
hold the regulator_list_mutex around this call. To avoid this rather
than holding the lock around a large portion of the registration code,
just hold the lock when aquiring any GPIOs and setting up supplies
because these sections may add entries to the regulator_map_list and
regulator_ena_gpio_list, respectively.

Signed-off-by: Jon Hunter 
---
 drivers/regulator/core.c | 31 ---
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 754f3b4c2218..4f57a1832079 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3127,8 +3127,13 @@ static int _regulator_get_voltage(struct regulator_dev 
*rdev)
return ret;
if (bypassed) {
/* if bypassed the regulator must have a supply */
-   if (!rdev->supply)
-   return -EINVAL;
+   if (!rdev->supply) {
+   ret = regulator_resolve_supply(rdev);
+   if (ret < 0)
+   return ret;
+   if (!rdev->supply)
+   return -EINVAL;
+   }
 
return _regulator_get_voltage(rdev->supply->rdev);
}
@@ -3945,8 +3950,6 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
rdev->dev.of_node = of_node_get(config->of_node);
}
 
-   mutex_lock(_list_mutex);
-
mutex_init(>mutex);
rdev->reg_data = config->driver_data;
rdev->owner = regulator_desc->owner;
@@ -3971,7 +3974,9 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
 
if ((config->ena_gpio || config->ena_gpio_initialized) &&
gpio_is_valid(config->ena_gpio)) {
+   mutex_lock(_list_mutex);
ret = regulator_ena_gpio_request(rdev, config);
+   mutex_unlock(_list_mutex);
if (ret != 0) {
rdev_err(rdev, "Failed to request enable GPIO%d: %d\n",
 config->ena_gpio, ret);
@@ -3989,31 +3994,32 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
if (init_data)
constraints = _data->constraints;
 
-   ret = set_machine_constraints(rdev, constraints);
-   if (ret < 0)
-   goto wash;
-
if (init_data && init_data->supply_regulator)
rdev->supply_name = init_data->supply_regulator;
else if (regulator_desc->supply_name)
rdev->supply_name = regulator_desc->supply_name;
 
+   ret = set_machine_constraints(rdev, constraints);
+   if (ret < 0)
+   goto wash;
+
/* add consumers devices */
if (init_data) {
+   mutex_lock(_list_mutex);
for (i = 0; i < init_data->num_consumer_supplies; i++) {
ret = set_consumer_device_supply(rdev,
init_data->consumer_supplies[i].dev_name,
init_data->consumer_supplies[i].supply);
if (ret < 0) {
+   mutex_unlock(_list_mutex);
dev_err(dev, "Failed to set supply %s\n",
init_data->consumer_supplies[i].supply);
goto unset_supplies;
}
}
+   mutex_unlock(_list_mutex);
}
 
-   mutex_unlock(_list_mutex);
-
ret = device_register(>dev);
if (ret != 0) {
put_device(>dev);
@@ -4030,13 +4036,16 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
return rdev;
 
 unset_supplies:
+   mutex_lock(_list_mutex);
unset_regulator_supplies(rdev);
+   mutex_unlock(_list_mutex);
 wash:
kfree(rdev->constraints);
+