This patch is from John Rose <johnrose@austin.ibm.com>.

The function __ioremap_explicit() misses a possible (obscure) case when
reserving the imalloc area for the new region.  This can result in the
unexpected DLPAR-add failure for an I/O slot.  The failure will be
characterized by a kernel message resembling "could not obtain imalloc area
for ea 0x..." Here's an explanation:

At boot time, imalloc regions are created for the ranges of all PHBs.  Upon
removal of a child slot for one of these PHBs, the imalloc region is split
so that the region for the child slot can be removed.

A GFW testcase revealed the following scenario.  A PHB is remapped at boot
for virtual address range A through C.  At boot, the partition owns a slot
that spans from A to B.  This slot is DLPAR-removed, leaving an imalloc
region from B to C.  At this point, the user DLPAR adds an EADS slot that
was not present at boot, but is a child of the PHB.  The new slot happens
to have a range that directly matches the leftover PHB range, from B to C. 
The existing code does not expect this, so the operation fails.
Signed-off-by: John Rose <johnrose@austin.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>