How about this to handle the "call yourself" semantic?

In the other archs, there is more factoring of smp call code, and more care in
the use of get_cpu(). That can be a follow-up MIPS patch.

Signed-off-by: Peter Watkins <[EMAIL PROTECTED]>

---
diff --git a/arch/mips/kernel/smp.c b/arch/mips/kernel/smp.c
index 67edfa7..33712ff 100644
--- a/arch/mips/kernel/smp.c
+++ b/arch/mips/kernel/smp.c
@@ -203,6 +203,61 @@ void smp_call_function_interrupt(void)
        }
 }
 
+int smp_call_function_single (int cpu, void (*func) (void *info), void *info, 
int retry,
+                             int wait)
+{
+       struct call_data_struct data;
+       int me;
+
+       /*
+        * Can die spectacularly if this CPU isn't yet marked online
+        */
+       if (!cpu_online(cpu))
+               return 0;
+
+       me = get_cpu();
+       BUG_ON(!cpu_online(me));
+
+       if (cpu == me) {
+               local_irq_disable()
+               func(info);
+               local_irq_enable();
+               put_cpu();
+               return 0;
+       }
+
+       /* Can deadlock when called with interrupts disabled */
+       WARN_ON(irqs_disabled());
+
+       data.func = func;
+       data.info = info;
+       atomic_set(&data.started, 0);
+       data.wait = wait;
+       if (wait)
+               atomic_set(&data.finished, 0);
+
+       spin_lock(&smp_call_lock);
+       call_data = &data;
+       smp_mb();
+
+       /* Send a message to the other CPU */
+       core_send_ipi(cpu, SMP_CALL_FUNCTION);
+
+       /* Wait for response */
+       /* FIXME: lock-up detection, backtrace on lock-up */
+       while (atomic_read(&data.started) != 1)
+               barrier();
+
+       if (wait)
+               while (atomic_read(&data.finished) != 1)
+                       barrier();
+       call_data = NULL;
+       spin_unlock(&smp_call_lock);
+
+       put_cpu();
+       return 0;
+}
+
 static void stop_this_cpu(void *dummy)
 {
        /*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to