regulator: bd71815: bd71828: bd9576: Use dev_err_probe()

The dev_err_probe() has (at least) following benefits over dev_err()
when printing an error print for a failed function call at a device
driver probe:
        - Omit error level print if error is 'EPRBE_DEFER'
        - Standardized print format for returned error
        - return the error value allowing shortening calls like:

        if (ret) {
                dev_err(...);
                return ret;
        }

        to

        if (ret)
                return dev_err_probe(...);

Convert the ROHM BD71828, ROHM BD71815 and ROHM BD9576 regulator drivers
to use the dev_err_probe() when returned error is not hard-coded constant.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/0b644da4a8f58558ffe474d2593f85c46de2f965.1669203610.git.mazziesaccount@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>

1 files changed, 25 insertions, 29 deletions

diff --git a/drivers/regulator/bd9576-regulator.c b/drivers/regulator/bd9576-regulator.c
index 393c8693b327..02c70768652b 100644
--- a/drivers/regulator/bd9576-regulator.c
+++ b/drivers/regulator/bd9576-regulator.c
@@ -953,30 +953,28 @@ static int bd957x_probe(struct platform_device *pdev)
 					   dev_fwnode(pdev->dev.parent),
 					   "rohm,vout1-en", GPIOD_OUT_LOW,
 					   "vout1-en");
-		if (!IS_ERR(en)) {
-			/* VOUT1_OPS gpio ctrl */
-			/*
-			 * Regulator core prioritizes the ena_gpio over
-			 * enable/disable/is_enabled callbacks so no need to
-			 * clear them. We can still use same ops
-			 */
+
+		/* VOUT1_OPS gpio ctrl */
+		/*
+		 * Regulator core prioritizes the ena_gpio over
+		 * enable/disable/is_enabled callbacks so no need to clear them
+		 * even if GPIO is used. So, we can still use same ops.
+		 *
+		 * In theory it is possible someone wants to set vout1-en LOW
+		 * during OTP loading and set VOUT1 to be controlled by GPIO -
+		 * but control the GPIO from some where else than this driver.
+		 * For that to work we should unset the is_enabled callback
+		 * here.
+		 *
+		 * I believe such case where rohm,vout1-en-low is set and
+		 * vout1-en-gpios is not is likely to be a misconfiguration.
+		 * So let's just err out for now.
+		 */
+		if (!IS_ERR(en))
 			config.ena_gpiod = en;
-		} else {
-			/*
-			 * In theory it is possible someone wants to set
-			 * vout1-en LOW during OTP loading and set VOUT1 to be
-			 * controlled by GPIO - but control the GPIO from some
-			 * where else than this driver. For that to work we
-			 * should unset the is_enabled callback here.
-			 *
-			 * I believe such case where rohm,vout1-en-low is set
-			 * and vout1-en-gpios is not is likely to be a
-			 * misconfiguration. So let's just err out for now.
-			 */
-			dev_err(&pdev->dev,
-				"Failed to get VOUT1 control GPIO\n");
-			return PTR_ERR(en);
-		}
+		else
+			return dev_err_probe(&pdev->dev, PTR_ERR(en),
+					"Failed to get VOUT1 control GPIO\n");
 	}
 
 	/*
@@ -1037,12 +1035,10 @@ static int bd957x_probe(struct platform_device *pdev)
 
 		r->rdev = devm_regulator_register(&pdev->dev, desc,
 							   &config);
-		if (IS_ERR(r->rdev)) {
-			dev_err(&pdev->dev,
-				"failed to register %s regulator\n",
-				desc->name);
-			return PTR_ERR(r->rdev);
-		}
+		if (IS_ERR(r->rdev))
+			return dev_err_probe(&pdev->dev, PTR_ERR(r->rdev),
+					"failed to register %s regulator\n",
+					desc->name);
 		/*
 		 * Clear the VOUT1 GPIO setting - rest of the regulators do not
 		 * support GPIO control