All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Arnd Bergmann <arnd@arndb.de>, linux-arm-kernel@lists.infradead.org
Cc: Zhangfei Gao <zhangfei.gao@linaro.org>,
	Wolfram Sang <wsa@the-dreams.de>,
	mika.westerberg@linux.intel.com, jarkko.nikula@linux.intel.com,
	p.zabel@pengutronix.de, linux-i2c@vger.kernel.org
Subject: Re: [PATCH v3] i2c: designware: add reset interface
Date: Wed, 04 Jan 2017 17:35:19 +0200	[thread overview]
Message-ID: <1483544119.9552.223.camel@linux.intel.com> (raw)
In-Reply-To: <2921529.fKUMSWjgsl@wuerfel>

On Wed, 2017-01-04 at 15:55 +0100, Arnd Bergmann wrote:
> On Friday, December 23, 2016 9:40:51 PM CET Zhangfei Gao wrote:
> > @@ -176,6 +177,14 @@ static int dw_i2c_plat_probe(struct
> > platform_device *pdev)
> >         dev->irq = irq;
> >         platform_set_drvdata(pdev, dev);
> >  
> > +       dev->rst = devm_reset_control_get_optional_exclusive(&pdev-
> > >dev, NULL);
> > +       if (IS_ERR(dev->rst)) {
> > +               if (PTR_ERR(dev->rst) == -EPROBE_DEFER)
> > +                       return -EPROBE_DEFER;
> > +       } else {
> > +               reset_control_deassert(dev->rst);
> > +       }
> > +
> 
> Sorry for the late reply, I only now stumbled over this. I think it's
> generally wrong to ignore any error aside from -EPROBE_DEFER. It's
> better to single-out the error conditions you want to ignore (e.g.
> no reset specified) and ignore those but return an error for
> all other problems.

Which means that reset framework whenever work _optional is used should
return error iff (mind two f:s) there is a problem with existing
control.

> 
> > @@ -270,10 +280,18 @@ static int dw_i2c_plat_probe(struct
> > platform_device *pdev)
> >         }
> >  
> >         r = i2c_dw_probe(dev);
> > -       if (r && !dev->pm_runtime_disabled)
> > -               pm_runtime_disable(&pdev->dev);
> > +       if (r)
> > +               goto exit_probe;
> >  
> >         return r;
> > +
> > +exit_probe:
> > +       if (!dev->pm_runtime_disabled)
> > +               pm_runtime_disable(&pdev->dev);
> > +exit_reset:
> > +       if (!IS_ERR_OR_NULL(dev->rst))
> > +               reset_control_assert(dev->rst);
> > +       return r;
> > 
> 
> try to avoid the IS_ERR_OR_NULL() check, it usually indicates either
> a bad interface, or that the interface is used wrong.

Please, fix reset framework first than.

For my understanding:
It should return NULL for optional reset control.
It should not fail on NULL argument.


> In this case, I think we can't get here with a NULL dev->rst
> pointer, so it's better to only check IS_ERR, or to explicitly
> set the pointer to NULL in case there is no reset line.
> 
> 	Arnd

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

WARNING: multiple messages have this Message-ID (diff)
From: andriy.shevchenko@linux.intel.com (Andy Shevchenko)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3] i2c: designware: add reset interface
Date: Wed, 04 Jan 2017 17:35:19 +0200	[thread overview]
Message-ID: <1483544119.9552.223.camel@linux.intel.com> (raw)
In-Reply-To: <2921529.fKUMSWjgsl@wuerfel>

On Wed, 2017-01-04 at 15:55 +0100, Arnd Bergmann wrote:
> On Friday, December 23, 2016 9:40:51 PM CET Zhangfei Gao wrote:
> > @@ -176,6 +177,14 @@ static int dw_i2c_plat_probe(struct
> > platform_device *pdev)
> > ????????dev->irq = irq;
> > ????????platform_set_drvdata(pdev, dev);
> > ?
> > +???????dev->rst = devm_reset_control_get_optional_exclusive(&pdev-
> > >dev, NULL);
> > +???????if (IS_ERR(dev->rst)) {
> > +???????????????if (PTR_ERR(dev->rst) == -EPROBE_DEFER)
> > +???????????????????????return -EPROBE_DEFER;
> > +???????} else {
> > +???????????????reset_control_deassert(dev->rst);
> > +???????}
> > +
> 
> Sorry for the late reply, I only now stumbled over this. I think it's
> generally wrong to ignore any error aside from -EPROBE_DEFER. It's
> better to single-out the error conditions you want to ignore (e.g.
> no reset specified) and ignore those but return an error for
> all other problems.

Which means that reset framework whenever work _optional is used should
return error iff (mind two f:s) there is a problem with existing
control.

> 
> > @@ -270,10 +280,18 @@ static int dw_i2c_plat_probe(struct
> > platform_device *pdev)
> > ????????}
> > ?
> > ????????r = i2c_dw_probe(dev);
> > -???????if (r && !dev->pm_runtime_disabled)
> > -???????????????pm_runtime_disable(&pdev->dev);
> > +???????if (r)
> > +???????????????goto exit_probe;
> > ?
> > ????????return r;
> > +
> > +exit_probe:
> > +???????if (!dev->pm_runtime_disabled)
> > +???????????????pm_runtime_disable(&pdev->dev);
> > +exit_reset:
> > +???????if (!IS_ERR_OR_NULL(dev->rst))
> > +???????????????reset_control_assert(dev->rst);
> > +???????return r;
> > 
> 
> try to avoid the IS_ERR_OR_NULL() check, it usually indicates either
> a bad interface, or that the interface is used wrong.

Please, fix reset framework first than.

For my understanding:
It should return NULL for optional reset control.
It should not fail on NULL argument.


> In this case, I think we can't get here with a NULL dev->rst
> pointer, so it's better to only check IS_ERR, or to explicitly
> set the pointer to NULL in case there is no reset line.
> 
> 	Arnd

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

  reply	other threads:[~2017-01-04 15:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-23 13:40 [PATCH v3] i2c: designware: add reset interface Zhangfei Gao
2016-12-23 13:40 ` Zhangfei Gao
2017-01-04 14:55 ` Arnd Bergmann
2017-01-04 14:55   ` Arnd Bergmann
2017-01-04 15:35   ` Andy Shevchenko [this message]
2017-01-04 15:35     ` Andy Shevchenko
2017-01-06 11:32     ` Arnd Bergmann
2017-01-06 11:32       ` Arnd Bergmann

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=1483544119.9552.223.camel@linux.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=p.zabel@pengutronix.de \
    --cc=wsa@the-dreams.de \
    --cc=zhangfei.gao@linaro.org \
    /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.