From: Greg KH <greg@kroah.com>
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PCI fixes for 2.6.9
Date: Tue, 19 Oct 2004 15:42:19 -0700 [thread overview]
Message-ID: <10982257394160@kroah.com> (raw)
In-Reply-To: <10982257393636@kroah.com>
ChangeSet 1.1997.37.57, 2004/10/06 13:53:18-07:00, johnrose@austin.ibm.com
[PATCH] PCI Hotplug: RPA DLPAR - remove error check
Here's a really long explanation for a really short patch! :)
As an unfortunate side effect of runtime addition/removal of PCI Host Bridges,
the RPA DLPAR driver can no longer depend on the success of ioremap_explicit()
(and therefore remap_page_range()) for the case of DLPAR adding an I/O Slot.
Without addressing this, an attempt to add the first child slot of a newly
added PHB will fail when __ioremap_explicit() determines the mappings for that
range to already exist.
For a little context, __ioremap_explicit() creates mappings for the range of a
newly added slot. Here's why these calls will be expected to fail in some
cases. Keep in mind that at boot-time, the PPC64 kernel calls ioremap() for
the entire range spanned by each PHB. Consider the following scenarios of
DLPAR-adding an I/O slot.
1) Just after boot, one removes an I/O slot. At this point the range
associated with the parent PHB is fragmented, and the child range for the
slot in question is iounmap()'ed. One then re-adds the slot, at which point
remap_page_range()/ioremap_explicit() restores the mappings that were
previously removed.
2) One adds a new PHB, at which point the ppc64-specific addition ioremaps the
entire PHB range. One then performs a DLPAR-add of a child slot of that
PHB. At this point, mappings already exist for the range of the slot to
be added. So remap_page_range()/ioremap_explicit() will fail at this point.
The problem is, there's not a good way to distinguish between cases 1 and 2
from the perspective of the DLPAR driver. Because of that, I believe the
correct solution to be:
- Removal of relevant error prints from iounmap_explicit(), which is only used
for DLPAR.
- Removal of error code checks from the RPA driver
Signed-off-by: John Rose <johnrose@austin.ibm.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
drivers/pci/hotplug/rpadlpar_core.c | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff -Nru a/drivers/pci/hotplug/rpadlpar_core.c b/drivers/pci/hotplug/rpadlpar_core.c
--- a/drivers/pci/hotplug/rpadlpar_core.c 2004-10-19 15:22:29 -07:00
+++ b/drivers/pci/hotplug/rpadlpar_core.c 2004-10-19 15:22:29 -07:00
@@ -158,12 +158,8 @@
dn->bussubno = child->number;
- /* ioremap() for child bus */
- if (remap_bus_range(child)) {
- printk(KERN_ERR "%s: could not ioremap() child bus\n",
- __FUNCTION__);
- return 1;
- }
+ /* ioremap() for child bus, which may or may not succeed */
+ remap_bus_range(child);
return 0;
}
next prev parent reply other threads:[~2004-10-19 23:01 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-19 22:37 [BK PATCH] " Greg KH
2004-10-19 22:42 ` [PATCH] " Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH [this message]
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-19 22:42 ` Greg KH
2004-10-20 8:10 ` Russell King
2004-10-22 23:45 ` Greg KH
2004-10-24 16:47 ` Alan Cox
2004-11-20 18:45 ` Russell King
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=10982257394160@kroah.com \
--to=greg@kroah.com \
--cc=linux-kernel@vger.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
Powered by JetHome