On 2016年07月26日 17:00, John Keeping wrote:
On Tue, 26 Jul 2016 14:11:47 +0800, Caesar Wang wrote:
SARADC controller needs to be reset before programming it, otherwise
it will not function properly.
Signed-off-by: Caesar Wang <wxt@xxxxxxxxxxxxxx>
Cc: Jonathan Cameron <jic23@xxxxxxxxxx>
Cc: Heiko Stuebner <heiko@xxxxxxxxx>
Cc: Rob Herring <robh+dt@xxxxxxxxxx>
Cc: linux-iio@xxxxxxxxxxxxxxx
Cc: linux-rockchip@xxxxxxxxxxxxxxxxxxx
---
diff --git a/drivers/iio/adc/rockchip_saradc.c b/drivers/iio/adc/rockchip_saradc.c
index f9ad6c2..2f0e110 100644
--- a/drivers/iio/adc/rockchip_saradc.c
+++ b/drivers/iio/adc/rockchip_saradc.c
@@ -218,6 +231,13 @@ static int rockchip_saradc_probe(struct platform_device *pdev)
if (IS_ERR(info->regs))
return PTR_ERR(info->regs);
+ info->reset = devm_reset_control_get(&pdev->dev, "saradc-apb");
+ if (IS_ERR(info->reset)) {
+ ret = PTR_ERR(info->reset);
+ dev_err(&pdev->dev, "failed to get saradc reset: %d\n", ret);
+ return ret;
+ }
Does this need to handle ENOENT so as to avoid failing with old device
tree blobs?
I'm no sure why we have to support the old device tree,
We can apply this series patches if we need to support the reset property.
---
Maybe, I can follow you suggestion to handle the ENOENT, as following:
+ /*
+ * The reset should be an optional property, as it should work
+ * with old devicetrees as well
+ */
+ info->reset = devm_reset_control_get(&pdev->dev, "saradc-apb");
+ if (IS_ERR(info->reset)) {
+ if (PTR_ERR(info->reset) == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ return ret;
+ }
+ dev_dbg(&pdev->dev, "no reset control found\n");
+ info->reset = NULL;
+ }
...
+ if (info->reset)
+ rockchip_saradc_reset_controller(info->reset);
+
How about it?
-
Caesar
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-rockchip
--
caesar wang | software engineer | wxt@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
