From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755967AbcGZKuK (ORCPT ); Tue, 26 Jul 2016 06:50:10 -0400 Received: from regular1.263xmail.com ([211.150.99.136]:42103 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752518AbcGZKuI (ORCPT ); Tue, 26 Jul 2016 06:50:08 -0400 X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 X-RL-SENDER: wxt@rock-chips.com X-FST-TO: john@metanate.com X-SENDER-IP: 103.29.142.67 X-LOGIN-NAME: wxt@rock-chips.com X-UNIQUE-TAG: <2b183ee51c80d8af828026a24e84f4c7> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Message-ID: <57974054.8040700@rock-chips.com> Date: Tue, 26 Jul 2016 18:49:56 +0800 From: Caesar Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John Keeping , Heiko Stuebner CC: Caesar Wang , devicetree@vger.kernel.org, linux-iio@vger.kernel.org, dianders@chromium.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, robh+dt@kernel.org, linux@roeck-us.net, jic23@kernel.org Subject: Re: [PATCH 1/4] iio: adc: rockchip_saradc: reset saradc controller before programming it References: <1469513510-1516-1-git-send-email-wxt@rock-chips.com> <20160726100007.5166e7f9.john@metanate.com> In-Reply-To: <20160726100007.5166e7f9.john@metanate.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >> Cc: Jonathan Cameron >> Cc: Heiko Stuebner >> Cc: Rob Herring >> Cc: linux-iio@vger.kernel.org >> Cc: linux-rockchip@lists.infradead.org >> --- >> >> 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@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip -- caesar wang | software engineer | wxt@rock-chip.com