Commit 88e0d40a authored by John Rose's avatar John Rose Committed by Greg Kroah-Hartman

[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: default avatarJohn Rose <johnrose@austin.ibm.com>
Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
parent 6d316d71
......@@ -158,12 +158,8 @@ static int pci_add_secondary_bus(struct device_node *dn,
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;
}
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment