All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Keeping <john@metanate.com>
To: Caesar Wang <wxt@rock-chips.com>
Cc: Heiko Stuebner <heiko@sntech.de>,
	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
Date: Tue, 26 Jul 2016 12:16:40 +0100	[thread overview]
Message-ID: <20160726121640.2d5d9045.john@metanate.com> (raw)
In-Reply-To: <57974054.8040700@rock-chips.com>

On Tue, 26 Jul 2016 18:49:56 +0800, Caesar Wang wrote:

> 
> 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@rock-chips.com>
> >> Cc: Jonathan Cameron <jic23@kernel.org>
> >> Cc: Heiko Stuebner <heiko@sntech.de>
> >> Cc: Rob Herring <robh+dt@kernel.org>
> >> 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;
> + }
> ...
> 
> How about it?

I think it's better to handle ENOENT specifically, we still want to fail
if some other errors like EINVAL is returned.

Something like this, perhaps?

    if (IS_ERR(info->reset)) {
        ret = PTR_ERR(info->reset);
        if (ret != -ENOENT)
            return ret;

        dev_dbg(&pdev->dev, "no reset control found\n");
        info->reset = NULL;
    }

Although I do wonder if a devm_reset_control_get_optional() helper would
be useful (this isn't the first time I've seen reset control added to
existing drivers).

WARNING: multiple messages have this Message-ID (diff)
From: John Keeping <john-HooS5bfzL4hWk0Htik3J/w@public.gmane.org>
To: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Cc: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org,
	jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Subject: Re: [PATCH 1/4] iio: adc: rockchip_saradc: reset saradc controller before programming it
Date: Tue, 26 Jul 2016 12:16:40 +0100	[thread overview]
Message-ID: <20160726121640.2d5d9045.john@metanate.com> (raw)
In-Reply-To: <57974054.8040700-TNX95d0MmH7DzftRWevZcw@public.gmane.org>

On Tue, 26 Jul 2016 18:49:56 +0800, Caesar Wang wrote:

> 
> 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-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> >> Cc: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >> Cc: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
> >> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >> Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >> Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.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;
> + }
> ...
> 
> How about it?

I think it's better to handle ENOENT specifically, we still want to fail
if some other errors like EINVAL is returned.

Something like this, perhaps?

    if (IS_ERR(info->reset)) {
        ret = PTR_ERR(info->reset);
        if (ret != -ENOENT)
            return ret;

        dev_dbg(&pdev->dev, "no reset control found\n");
        info->reset = NULL;
    }

Although I do wonder if a devm_reset_control_get_optional() helper would
be useful (this isn't the first time I've seen reset control added to
existing drivers).

WARNING: multiple messages have this Message-ID (diff)
From: John Keeping <john@metanate.com>
To: Caesar Wang <wxt@rock-chips.com>
Cc: Heiko Stuebner <heiko@sntech.de>,
	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
Date: Tue, 26 Jul 2016 12:16:40 +0100	[thread overview]
Message-ID: <20160726121640.2d5d9045.john@metanate.com> (raw)
In-Reply-To: <57974054.8040700@rock-chips.com>

On Tue, 26 Jul 2016 18:49:56 +0800, Caesar Wang wrote:

>=20
> On 2016=E5=B9=B407=E6=9C=8826=E6=97=A5 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@rock-chips.com>
> >> Cc: Jonathan Cameron <jic23@kernel.org>
> >> Cc: Heiko Stuebner <heiko@sntech.de>
> >> Cc: Rob Herring <robh+dt@kernel.org>
> >> 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/rockc=
hip_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);
> >>  =20
> >> +	info->reset =3D devm_reset_control_get(&pdev->dev, "saradc-apb");
> >> +	if (IS_ERR(info->reset)) {
> >> +		ret =3D 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?
>=20
> 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.
> ---
>=20
> Maybe, I can follow you suggestion to handle the ENOENT, as following:
>=20
> + /*
> + * The reset should be an optional property, as it should work
> + * with old devicetrees as well
> + */
> + info->reset =3D devm_reset_control_get(&pdev->dev, "saradc-apb");
> + if (IS_ERR(info->reset)) {
> + if (PTR_ERR(info->reset) =3D=3D -EPROBE_DEFER) {
> + ret =3D -EPROBE_DEFER;
> + return ret;
> + }
> + dev_dbg(&pdev->dev, "no reset control found\n");
> + info->reset =3D NULL;
> + }
> ...
>=20
> How about it?

I think it's better to handle ENOENT specifically, we still want to fail
if some other errors like EINVAL is returned.

Something like this, perhaps?

    if (IS_ERR(info->reset)) {
        ret =3D PTR_ERR(info->reset);
        if (ret !=3D -ENOENT)
            return ret;

        dev_dbg(&pdev->dev, "no reset control found\n");
        info->reset =3D NULL;
    }

Although I do wonder if a devm_reset_control_get_optional() helper would
be useful (this isn't the first time I've seen reset control added to
existing drivers).

  reply	other threads:[~2016-07-26 11:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-26  6:11 [PATCH 1/4] iio: adc: rockchip_saradc: reset saradc controller before programming it Caesar Wang
2016-07-26  6:11 ` Caesar Wang
2016-07-26  6:11 ` [PATCH 2/4] arm64: dts: rockchip: add the saradc for rk3399 Caesar Wang
2016-07-26  6:11 ` [PATCH 3/4] arm64: dts: rockchip: add reset saradc node for rk3368 SoCs Caesar Wang
2016-07-26  6:11   ` Caesar Wang
2016-07-26  6:11 ` [PATCH 4/4] arm: dts: rockchip: add reset node for the exist saradc SoCs Caesar Wang
2016-07-26  6:11   ` Caesar Wang
2016-07-26  9:00 ` [PATCH 1/4] iio: adc: rockchip_saradc: reset saradc controller before programming it John Keeping
2016-07-26 10:49   ` Caesar Wang
2016-07-26 11:16     ` John Keeping [this message]
2016-07-26 11:16       ` John Keeping
2016-07-26 11:16       ` John Keeping
2016-07-26  9:17 ` Heiko Stübner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160726121640.2d5d9045.john@metanate.com \
    --to=john@metanate.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=heiko@sntech.de \
    --cc=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux@roeck-us.net \
    --cc=robh+dt@kernel.org \
    --cc=wxt@rock-chips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.