From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Gavin Shan <shangw@linux.vnet.ibm.com>
Subject: Re: [PATCH 1/8] PCI: Add pcibios_stop_dev()
Date: Sat, 06 Jul 2013 08:36:47 +1000 [thread overview]
Message-ID: <1373063807.4446.10.camel@pasglop> (raw)
In-Reply-To: <CAErSpo7QGD99HM1fEcvGi-9h3HX6C8nu1mzJHnMMUKWTNO0vnw@mail.gmail.com>
On Fri, 2013-07-05 at 12:49 -0600, Bjorn Helgaas wrote:
> We already have pcibios_release_device() (just merged for v3.11).
> Would that work for you? I haven't seen your whole series, so I can't
> tell whether you need something different.
Maybe... Gavin's original hook applies when the device is removed
from the tree, your new hook when the refcount expires and the
structure is about to be freed...
I *suspect* that's fine but I'll need to have a closer look (or wait
for Gavin to be back from vacation :-)
BTW. One thing we do in EEH is that if we get an error and the driver
for the device doesn't implement recovery, we simulate a hotplug.
IE. We unplug the device (currently removing it), reset it (or the
bus it's on, whatever applies, which lifts the fence established by
the EEH hardware), and re-plug it.
The current method really removes the device from the PCI subsystem,
and "plugs" it back. IE. We rescan the slot, and might even end up
re-assigning resources, which I'm not too fan about. It's also unclear
what quirks gets called in that re-plug case, etc...
I'm wondering whether it might be better to keep the pci_dev around,
just mark it blocked for user access, unbind the driver, reset, restore
the BARs to their original values, unblock and re-bind.
What's your take on this ?
Cheers,
Ben.
next prev parent reply other threads:[~2013-07-05 22:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-05 2:57 [PATCH v1 0/8] EEH Followup Fixes (II) Gavin Shan
2013-07-05 2:57 ` [PATCH 1/8] PCI: Add pcibios_stop_dev() Gavin Shan
2013-07-05 3:08 ` Benjamin Herrenschmidt
2013-07-05 18:49 ` Bjorn Helgaas
2013-07-05 22:36 ` Benjamin Herrenschmidt [this message]
2013-07-05 22:49 ` Bjorn Helgaas
2013-07-05 23:05 ` Benjamin Herrenschmidt
2013-07-05 2:57 ` [PATCH 2/8] powerpc/eeh: Export functions for hotplug Gavin Shan
2013-07-05 2:57 ` [PATCH 3/8] powerpc/pci: Override pcibios_stop_dev() Gavin Shan
2013-07-05 2:57 ` [PATCH 4/8] PCI/hotplug: Needn't remove EEH cache again Gavin Shan
2013-07-05 18:51 ` Bjorn Helgaas
2013-07-05 2:57 ` [PATCH 5/8] powerpc/eeh: Keep PE during hotplug Gavin Shan
2013-07-05 2:57 ` [PATCH 6/8] powerpc/eeh: Tranverse EEH devices with safe mode Gavin Shan
2013-07-05 2:57 ` [PATCH 7/8] powerpc/pci: Partial hotplug support Gavin Shan
2013-07-05 2:57 ` [PATCH 8/8] powerpc/eeh: Support partial hotplug Gavin Shan
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=1373063807.4446.10.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=bhelgaas@google.com \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=shangw@linux.vnet.ibm.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;
as well as URLs for NNTP newsgroup(s).