Skip to contentSkip to conversation

regulator: Remove mc13xxx_unlock in regulator_register failure path

PATCH In review Axel Lin 2 participants 3 messages May 3, 2011 Voltage and current regulator framework

lore
Share & tools
lore

Axel Lin

author
#0 lore raw

PATCH 1/1 regulator: Remove mc13xxx_unlock in regulator_register failure path

We do not hold the mutex_lock of struct mc13xxx while calling regulator_register, Thus remove mc13xxx_unlock in regulator_register failure path.

Signed-off-by Axel Lin <[email protected]>
---
 drivers/regulator/mc13892-regulator.c |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)
drivers/regulator/mc13892-regulator.c +9 -4
index 1b8f739..38e805d 100644
@@ -537,8 +537,10 @@ static int __devinit mc13892_regulator_probe(struct platform_device *pdev)
 
 	mc13xxx_lock(mc13892);
 	ret = mc13xxx_reg_read(mc13892, MC13892_REVISION, &val);
-	if (ret)
+	if (ret) {
+		mc13xxx_unlock(mc13892);
 		goto err_free;
+	}
 
 	/* enable switch auto mode */
 	if ((val & 0x0000FFFF) == 0x45d0) {

@@ -547,16 +549,20 @@ static int __devinit mc13892_regulator_probe(struct platform_device *pdev)
 			MC13892_SWITCHERS4_SW2MODE_M,
 			MC13892_SWITCHERS4_SW1MODE_AUTO |
 			MC13892_SWITCHERS4_SW2MODE_AUTO);
-		if (ret)
+		if (ret) {
+			mc13xxx_unlock(mc13892);
 			goto err_free;
+		}
 
 		ret = mc13xxx_reg_rmw(mc13892, MC13892_SWITCHERS5,
 			MC13892_SWITCHERS5_SW3MODE_M |
 			MC13892_SWITCHERS5_SW4MODE_M,
 			MC13892_SWITCHERS5_SW3MODE_AUTO |
 			MC13892_SWITCHERS5_SW4MODE_AUTO);
-		if (ret)
+		if (ret) {
+			mc13xxx_unlock(mc13892);
 			goto err_free;
+		}
 	}
 	mc13xxx_unlock(mc13892);
 

@@ -586,7 +592,6 @@ err:
 		regulator_unregister(priv->regulators[i]);
 
 err_free:
-	mc13xxx_unlock(mc13892);
 	kfree(priv);
 
 	return ret;
Signature · 1 line
1.7.1
#1 lore raw
Quoted 2 lines · Axel Lin

We do not hold the mutex_lock of struct mc13xxx while calling regulator_register, Thus remove mc13xxx_unlock in regulator_register failure path.

This feels painful, we shouldn't have to be faffing about with the lock like this for basic I/O operations. It feels like we should be pushing the lock down into the register access functions - looking at the driver I can't really see any reason why all this stuff is being done by hand, especially when we've got explicit read/modify/write bitmask operations.

author
#2 lore raw

hi Mark,

Quoted 6 lines

This feels painful, we shouldn't have to be faffing about with the lock like this for basic I/O operations.  It feels like we should be pushing the lock down into the register access functions - looking at the driver I can't really see any reason why all this stuff is being done by hand, especially when we've got explicit read/modify/write bitmask operations.

Agreed. Thanks for the review. I'll send a patch for it.

Regards,
Axel