[PATCH] __ioremap_explicit() criterion change

[John Rose]

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 at austin.ibm.com>

diff -Nru a/arch/ppc64/mm/init.c b/arch/ppc64/mm/init.c
--- a/arch/ppc64/mm/init.c	Wed Oct 20 11:17:47 2004
+++ b/arch/ppc64/mm/init.c	Wed Oct 20 11:17:47 2004
@@ -263,7 +263,8 @@
 		 */
 		;
 	} 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) {
 			printk(KERN_ERR "could not obtain imalloc area for ea 0x%lx\n", ea);
 			return 1;