From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: "Krzysztof Wilczyński" <kw@linux.com>,
"Fabio Estevam" <festevam@gmail.com>
Cc: helgaas@kernel.org, jingoohan1@gmail.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 Mar 2021 11:10:10 +0000 [thread overview]
Message-ID: <20210323111010.GC29286@e121166-lin.cambridge.arm.com> (raw)
In-Reply-To: <YDVxBzH/9ePDhy4v@rocinante>
On Tue, Feb 23, 2021 at 10:17:59PM +0100, Krzysztof Wilczyński wrote:
> 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.
Fabio, what's the plan with this patch ?
Lorenzo
next prev parent reply other threads:[~2021-03-23 11:11 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
2021-03-23 11:10 ` Lorenzo Pieralisi [this message]
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=20210323111010.GC29286@e121166-lin.cambridge.arm.com \
--to=lorenzo.pieralisi@arm.com \
--cc=festevam@gmail.com \
--cc=helgaas@kernel.org \
--cc=jingoohan1@gmail.com \
--cc=kw@linux.com \
--cc=linux-pci@vger.kernel.org \
--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).