From: Stephen Rothwell <sfr@canb.auug.org.au>

in_atomic() in viopath.c was just used to determine if we had initialised
enough to be able to wait in a semaphore (i.e.  schedule).  Thus it can be
replaced now with checking system_state for SYSTEM_RUNNING.

Test booted on iSeries (which is the only place it is used).

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 25-akpm/arch/ppc64/kernel/viopath.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff -puN arch/ppc64/kernel/viopath.c~ppc64-dont-use-in_atomic arch/ppc64/kernel/viopath.c
--- 25/arch/ppc64/kernel/viopath.c~ppc64-dont-use-in_atomic	2005-03-11 12:32:10.000000000 -0800
+++ 25-akpm/arch/ppc64/kernel/viopath.c	2005-03-11 12:32:10.000000000 -0800
@@ -79,7 +79,7 @@ static void handleMonitorEvent(struct Hv
 /*
  * We use this structure to handle asynchronous responses.  The caller
  * blocks on the semaphore and the handler posts the semaphore.  However,
- * if in_atomic() is true in the caller, then wait_atomic is used ...
+ * if system_state is not SYSTEM_RUNNING, then wait_atomic is used ...
  */
 struct doneAllocParms_t {
 	struct semaphore *sem;
@@ -465,7 +465,7 @@ static int allocateEvents(HvLpIndex remo
 	DECLARE_MUTEX_LOCKED(Semaphore);
 	atomic_t wait_atomic;
 
-	if (in_atomic()) {
+	if (system_state != SYSTEM_RUNNING) {
 		parms.used_wait_atomic = 1;
 		atomic_set(&wait_atomic, 1);
 		parms.wait_atomic = &wait_atomic;
@@ -475,7 +475,7 @@ static int allocateEvents(HvLpIndex remo
 	}
 	mf_allocate_lp_events(remoteLp, HvLpEvent_Type_VirtualIo, 250,	/* It would be nice to put a real number here! */
 			    numEvents, &viopath_donealloc, &parms);
-	if (in_atomic()) {
+	if (system_state != SYSTEM_RUNNING) {
 		while (atomic_read(&wait_atomic))
 			mb();
 	} else
_