All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Himanshu Jha <himanshujha199640@gmail.com>,
	bhelgaas@google.com, jonathanh@nvidia.com,
	linux-tegra@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PCI: tegra: Use PTR_ERR_OR_ZERO
Date: Wed, 30 Aug 2017 16:25:47 +0200	[thread overview]
Message-ID: <20170830142547.GC1361@ulmo> (raw)
In-Reply-To: <20170830135931.GA18250@bhelgaas-glaptop.roam.corp.google.com>

[-- Attachment #1: Type: text/plain, Size: 2639 bytes --]

On Wed, Aug 30, 2017 at 08:59:31AM -0500, Bjorn Helgaas wrote:
> On Tue, Aug 29, 2017 at 03:55:17PM +0200, Thierry Reding wrote:
> > On Tue, Aug 29, 2017 at 07:09:00PM +0530, Himanshu Jha wrote:
> > > Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
> > > 
> > > Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
> > > ---
> > >  drivers/pci/host/pci-tegra.c | 5 +----
> > >  1 file changed, 1 insertion(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
> > > index 9c40da5..90cda5b 100644
> > > --- a/drivers/pci/host/pci-tegra.c
> > > +++ b/drivers/pci/host/pci-tegra.c
> > > @@ -1156,10 +1156,7 @@ static int tegra_pcie_resets_get(struct tegra_pcie *pcie)
> > >  		return PTR_ERR(pcie->afi_rst);
> > >  
> > >  	pcie->pcie_xrst = devm_reset_control_get_exclusive(dev, "pcie_x");
> > > -	if (IS_ERR(pcie->pcie_xrst))
> > > -		return PTR_ERR(pcie->pcie_xrst);
> > > -
> > > -	return 0;
> > > +	return PTR_ERR_OR_ZERO(pcie->pcie_xrst);
> > >  }
> > 
> > I'm not a big fan of this construct because it's a pain to undo this if
> > ever we need to add code to this function. But since we do have scripts
> > that will flag this, I guess this would pop up every now and again. The
> > driver is unlikely to change in this part, too, so:
> 
> Thanks for pointing this out.  Do you know what the benefit of
> PTR_ERR_OR_ZERO() is?  To me, it makes the following code harder
> to read because the error tests are no longer parallel:
> 
>   ...
>   res->ahb_reset = devm_reset_control_get(dev, "ahb");
>   if (IS_ERR(res->ahb_reset))
>     return PTR_ERR(res->ahb_reset);
> 
>   res->por_reset = devm_reset_control_get(dev, "por");
>   if (IS_ERR(res->por_reset))
>     return PTR_ERR(res->por_reset);
> 
>   res->phy_reset = devm_reset_control_get(dev, "phy");
>   return PTR_ERR_OR_ZERO(res->phy_reset);
> 
> So I'd be inclined to avoid it unless there's some significant benefit.

Yeah, I don't like the optics much either. Aside from the fact that it
reduces the line count, I'm not aware of any benefits that this inline
function has. It doesn't have any side-effects or anything, just wraps
the common pattern into a single line.

Looking at the history of the semantic patch that is the basis for the
conversions (scripts/coccinelle/api/ptr_ret.cocci), or the static inline
function itself, no rationale is given for why people prefer this. I've
certainly seen such patches applied in some cases, but I've also seen
other maintainers (including myself) reject them because of personal
preference.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-08-30 14:25 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-29 13:39 [PATCH] PCI: tegra: Use PTR_ERR_OR_ZERO Himanshu Jha
2017-08-29 13:39 ` Himanshu Jha
2017-08-29 13:55 ` Thierry Reding
2017-08-29 14:14   ` Himanshu Jha
2017-08-29 15:09     ` Thierry Reding
2017-08-29 15:09       ` Thierry Reding
2017-08-30 13:59   ` Bjorn Helgaas
2017-08-30 14:25     ` Thierry Reding [this message]
2017-08-30 16:26       ` Bjorn Helgaas
2020-11-16 16:54 Sudip Mukherjee
2020-11-16 17:01 ` Thierry Reding

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=20170830142547.GC1361@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=himanshujha199640@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.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.