linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Krzysztof Wilczyński" <kw@linux.com>
To: Fabio Estevam <festevam@gmail.com>
Cc: helgaas@kernel.org, jingoohan1@gmail.com,
	lorenzo.pieralisi@arm.com, robh@kernel.org,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH] PCI: dwc: exynos: Check the phy_power_on() return value
Date: Tue, 23 Feb 2021 22:17:59 +0100	[thread overview]
Message-ID: <YDVxBzH/9ePDhy4v@rocinante> (raw)
In-Reply-To: <20210208174114.615811-1-festevam@gmail.com>

Hi Fabio,

Thank you for sending the patch over!

[...]
> This fixes the following Coverity error:
> 
> 	CID 1472841:  Error handling issues  (CHECKED_RETURN)
> 	Calling "phy_power_on" without checking return value (as is done elsewhere 40 out of 50 times).
> 	phy_power_on(ep->phy);
> 	phy_init(ep->phy);

This is good, however, you would need to wrap long lines, and that would
make the message from Coverity harder to read, etc.  Thus, it might be
better to use the "Addresses-Coverity-ID" which is becoming a de-facto
standard for referencing Coverity defects.  Check the following for some
examples:

   git log drivers/pci | grep 'Addresses-Coverity-ID:'

[...]         
> +	ret = phy_power_on(ep->phy);
> +	if (ret < 0)
> +		return ret;

I wonder if you would also have to call phy_exit() here, even though
eventually exynos_pcie_probe() would call it once the error propagates
all the way up the call stack.

Additionally, exynos_pcie_resume_noirq() does not do any error checking
after calling exynos_pcie_host_init() and does not call phy_exit()
either, and I am not sure if it should, though.

See some comments below.

> +
>  	phy_init(ep->phy);
[...]

A small nit here.  You can check for any non-zero return value, as
anything would indicate an error here.

I also have a suggestion.  Would you also be interested in addressing
two Coverity defects that were detected in exynos_pcie_host_init()?

These would be the one you addressed here (CID 1472841) in this patch
and the other would be:

  CID 1471267 (#1 of 1): Unchecked return value (CHECKED_RETURN)

Which is about checking return value from phy_init() that is called
immediately after phy_power_on() in exynos_pcie_host_init().

The error propagates from exynos_pcie_host_init() as follows:

  struct exynos_pcie_host_ops{}
    .host_init = exynos_pcie_host_init

  exynos_pcie_probe()              <-- phy_exit() called here if exynos_add_pcie_port() fails.
    exynos_add_pcie_port()
        dw_pcie_host_init()
          exynos_pcie_host_init()  <-- phy_power_on() and phy_init() called here.
            dw_pcie_host_init()
              struct pcie_port{}
                struct dw_pcie_host_ops{}
                  .host_init       <-- exynos_pcie_host_init() called via struct exynos_pcie_host_ops{}.

  struct exynos_pcie_pm_ops{}
    .suspend_noirq = exynos_pcie_suspend_noirq
    .resume_noirq = exynos_pcie_resume_noirq

  exynos_pcie_resume_noirq()
    exynos_pcie_host_init()        <-- called here, but without any error checking.

Thus, we could handle propagating error from both the phy_power_on() and
phy_init() in the same time, perhaps even in a single patch, or a small
series.

Also, since there is no error checking and/or handling that might be
returned from exynos_pcie_host_init() in the exynos_pcie_resume_noirq()
callback, then perhaps adding some error messages to be printed should
something bad happens regarding power management.  But this would
becompletely optional as there there is also no error checking and
handling in exynos_pcie_suspend_noirq() either.

Krzysztof

  reply	other threads:[~2021-02-23 21:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-08 17:41 [PATCH] PCI: dwc: exynos: Check the phy_power_on() return value Fabio Estevam
2021-02-23 21:17 ` Krzysztof Wilczyński [this message]
2021-03-23 11:10   ` Lorenzo Pieralisi
2021-03-23 11:33     ` Fabio Estevam
2021-03-23 11:49       ` Lorenzo Pieralisi

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=YDVxBzH/9ePDhy4v@rocinante \
    --to=kw@linux.com \
    --cc=festevam@gmail.com \
    --cc=helgaas@kernel.org \
    --cc=jingoohan1@gmail.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=robh@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).