From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bharat Kumar Gogada <bharatku@xilinx.com>,
Jingoo Han <jingoohan1@gmail.com>,
"joao.pinto@synopsys.com" <joao.pinto@synopsys.com>,
Ley Foon Tan <lftan@altera.com>,
Shawn Lin <shawn.lin@rock-chips.com>,
Michal Simek <michal.simek@xilinx.com>,
Jim Quinlan <jim2101024@gmail.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"rfi@lists.rocketboards.org" <rfi@lists.rocketboards.org>,
"linux-rockchip@lists.infradead.org"
<linux-rockchip@lists.infradead.org>
Subject: Re: Why do we check for "link-up" in *_pcie_valid_device()?
Date: Tue, 2 Jan 2018 11:37:50 +0000 [thread overview]
Message-ID: <20180102113750.GC10536@red-moon> (raw)
In-Reply-To: <20171222172815.GA55396@bhelgaas-glaptop.roam.corp.google.com>
On Fri, Dec 22, 2017 at 11:28:15AM -0600, Bjorn Helgaas wrote:
> On Fri, Dec 22, 2017 at 01:02:28PM +0000, Bharat Kumar Gogada wrote:
> > Bjorn wrote:
> >> In the PCI config access path, the *_pcie_valid_device() functions
> >> in the dwc, altera, rockchip, and xilinx drivers all check whether
> >> the link is up.
> >>
> >> I think this is racy because the link may go down after we check but
> >> before we perform the config access.
> >>
> >> What would blow up if we removed the *_pcie_link_up() checks?
> >>
> >> I'd like to either remove the checks or add comments about why the
> >> race is acceptable. If we've covered this before, I apologize.
> >> Adding a comment will keep me from pestering you about this again in
> >> the future.
>
> > In both Xilinx driver cases when link is down, hardware responds by
> > AXI DECERR/SLVERR status which causes an exception, synchronous
> > external abort to CPU. This causes system to hang, so we need this
> > check for both of our drivers. We will add comments.
>
> This is a problem, and checking whether the link is up is a workaround
> but not a real solution. That means your system may hang if the link
> happens to go down at the wrong time.
>
> A real solution would be to handle the synchronous external abort
> so it doesn't cause a system hang.
I still have no idea why checking (in a broken way) that the link
is up for _every_ given config access is a solution.
If, say, the link is down in xilinx_pcie_init_port(), what would bring
it up or, worded differently, why checking that the link is up for every
config access instead of host bridge probe time make this code any safer
?
It is not safe anyway, it would be good to understand though why the code
was written this way so that we can change it appropriately.
Thanks,
Lorenzo
next prev parent reply other threads:[~2018-01-02 11:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-14 22:58 Why do we check for "link-up" in *_pcie_valid_device()? Bjorn Helgaas
2017-12-15 18:39 ` Jingoo Han
2017-12-15 19:04 ` Bjorn Helgaas
2017-12-15 20:11 ` Bjorn Helgaas
2017-12-22 13:02 ` Bharat Kumar Gogada
2017-12-22 17:28 ` Bjorn Helgaas
2018-01-02 11:37 ` Lorenzo Pieralisi [this message]
2018-01-05 14:26 ` Bharat Kumar Gogada
2018-01-05 15:43 ` Lorenzo Pieralisi
2018-01-08 11:03 ` Lucas Stach
2018-01-08 11:24 ` Lorenzo Pieralisi
2018-01-02 12:24 ` Shawn Lin
2018-01-02 12:28 ` Shawn Lin
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=20180102113750.GC10536@red-moon \
--to=lorenzo.pieralisi@arm.com \
--cc=bharatku@xilinx.com \
--cc=helgaas@kernel.org \
--cc=jim2101024@gmail.com \
--cc=jingoohan1@gmail.com \
--cc=joao.pinto@synopsys.com \
--cc=lftan@altera.com \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=michal.simek@xilinx.com \
--cc=rfi@lists.rocketboards.org \
--cc=shawn.lin@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox