[PATCH v3 05/19] hwmon: (mr75203) skip reset-control deassert for SOCs that don't support it

Eliav Farber posted 19 patches 3 years, 7 months ago
There is a newer version of this series
[PATCH v3 05/19] hwmon: (mr75203) skip reset-control deassert for SOCs that don't support it
Posted by Eliav Farber 3 years, 7 months ago
Don't fail the probe function and don't deassert the reset controller if
a "reset" property doesn't exist in the device tree.

Change is done for SOCs that don't support a reset controller.

Signed-off-by: Eliav Farber <farbere@amazon.com>
---
V3 -> v2:
- Change "reset" property to be optional instead of skipping it.

 drivers/hwmon/mr75203.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/hwmon/mr75203.c b/drivers/hwmon/mr75203.c
index f89f7bb5d698..901030125127 100644
--- a/drivers/hwmon/mr75203.c
+++ b/drivers/hwmon/mr75203.c
@@ -525,14 +525,17 @@ static int mr75203_probe(struct platform_device *pdev)
 		return ret;
 	}
 
-	pvt->rst = devm_reset_control_get_exclusive(dev, NULL);
+	pvt->rst = devm_reset_control_get_optional_exclusive(dev, NULL);
 	if (IS_ERR(pvt->rst))
 		return dev_err_probe(dev, PTR_ERR(pvt->rst),
 				     "failed to get reset control\n");
 
-	ret = pvt_reset_control_deassert(dev, pvt);
-	if (ret)
-		return dev_err_probe(dev, ret, "cannot deassert reset control\n");
+	if (pvt->rst) {
+		ret = pvt_reset_control_deassert(dev, pvt);
+		if (ret)
+			return dev_err_probe(dev, ret,
+					     "cannot deassert reset control\n");
+	}
 
 	ret = regmap_read(pvt->c_map, PVT_IP_CONFIG, &val);
 	if(ret < 0)
-- 
2.37.1
Re: [PATCH v3 05/19] hwmon: (mr75203) skip reset-control deassert for SOCs that don't support it
Posted by Philipp Zabel 3 years, 7 months ago
Hi Eliav,

On Di, 2022-08-30 at 19:21 +0000, Eliav Farber wrote:
> Don't fail the probe function and don't deassert the reset controller if
> a "reset" property doesn't exist in the device tree.
> 
> Change is done for SOCs that don't support a reset controller.

Not strictly related to this patch, but reading the context I wonder
whether it is required that clock/reset are running/deasserted all the
time. Would it make sense to implement some kind of runtime PM?

> Signed-off-by: Eliav Farber <farbere@amazon.com>

This change is

Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>

regards
Philipp