From: Brian Norris <briannorris@chromium.org>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Alex Williamson <alex.williamson@redhat.com>,
Jeffy Chen <jeffy.chen@rock-chips.com>,
Shawn Lin <shawn.lin@rock-chips.com>
Subject: Re: [PATCH] pci: Disable master abort while waiting for an FLR to complete
Date: Mon, 15 May 2017 14:51:09 -0700 [thread overview]
Message-ID: <20170515215109.GA100668@google.com> (raw)
In-Reply-To: <20170515210033.GA58785@google.com>
On Mon, May 15, 2017 at 02:00:33PM -0700, Brian Norris wrote:
> On Mon, May 15, 2017 at 12:48:30PM -0700, Alexander Duyck wrote:
> > On Mon, May 15, 2017 at 9:36 AM, Brian Norris <briannorris@chromium.org> wrote:
> > > So there may be several implementation bugs with RK3399. I don't know
> > > how much can be fixed on Rockchip's side, vs. how much can be
> > > accomodated in the PCI core.
> >
> > This is the kind of thing we have PCIe quirks for if nothing else.
> > Odds are we should be able to work around it, it is just a matter of
> > knowing what all the quirks are.
>
> Maybe your imagination for "quirks" isn't creative enough :)
BTW, I meant to note that people have gone to some extreme lengths to
handle buggy / quirky RCs. Look at drivers/pci/dwc/pci-imx6.c, which
hooks all the way into the core ARM exception handling just to mask
aborts! (See imx6q_pcie_abort_handler.) And they have some patches
intended to fix crashes in 4.12-rc1 to hook synchronous aborts to return
"all 1's". But that's extremely invasive and not very precise (I don't
think that even checks the difference between PCI-induced aborts and
other system aborts?). Probably not gonna fly on ARM64 either...
Brian
[1] [PATCH] PCI: imx6: fix downstream bus scanning
https://patchwork.ozlabs.org/patch/760748/
next prev parent reply other threads:[~2017-05-15 21:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-12 18:13 [PATCH] pci: Disable master abort while waiting for an FLR to complete Alexander Duyck
2017-05-15 16:36 ` Brian Norris
2017-05-15 19:48 ` Alexander Duyck
2017-05-15 20:00 ` Alex Williamson
2017-05-15 21:00 ` Brian Norris
2017-05-15 21:51 ` Brian Norris [this message]
2017-06-14 22:34 ` Bjorn Helgaas
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=20170515215109.GA100668@google.com \
--to=briannorris@chromium.org \
--cc=alex.williamson@redhat.com \
--cc=alexander.duyck@gmail.com \
--cc=bhelgaas@google.com \
--cc=jeffy.chen@rock-chips.com \
--cc=linux-pci@vger.kernel.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 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.