[PATCH] ppc64: __ioremap_explicit() criterion change

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>

arch/ppc64/mm/init.c

@@ -263,7 +263,8 @@ int __ioremap_explicit(unsigned long pa, unsigned long ea,
 		 */
 		;
 	} else {
-		area = im_get_area(ea, size, IM_REGION_UNUSED|IM_REGION_SUBSET);
+		area = im_get_area(ea, size,
+			IM_REGION_UNUSED|IM_REGION_SUBSET|IM_REGION_EXISTS);
 		if (area == NULL) {
 			/* Expected when PHB-dlpar is in play */
 			return 1;