From f961171ed1c1e7ef10ba90eecb16a1dd42958c19 Mon Sep 17 00:00:00 2001 From: marius Date: Thu, 24 Dec 2009 12:27:22 +0000 Subject: - Don't check for a valid interrupt controller on every interrupt in intr_execute_handlers(). If we managed to get here without an associated interrupt controller we have way bigger problems. While at it predict stray vector interrupts as false as they are rather unlikely. - Don't blindly call the clear function of an interrupt controller when adding a handler in inthand_add() as interrupt controllers like the one driven by upa(4) are auto-clearing and thus provide NULL instead. --- sys/sparc64/sparc64/intr_machdep.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/sys/sparc64/sparc64/intr_machdep.c b/sys/sparc64/sparc64/intr_machdep.c index 9f9df1b..d0174b9 100644 --- a/sys/sparc64/sparc64/intr_machdep.c +++ b/sys/sparc64/sparc64/intr_machdep.c @@ -276,7 +276,7 @@ intr_execute_handlers(void *cookie) struct intr_vector *iv; iv = cookie; - if (iv->iv_ic == NULL || intr_event_handle(iv->iv_event, NULL) != 0) + if (__predict_false(intr_event_handle(iv->iv_event, NULL) != 0)) intr_stray_vector(iv); } @@ -377,7 +377,8 @@ inthand_add(const char *name, int vec, driver_filter_t *filt, #endif ic->ic_enable(iv); /* Ensure the interrupt is cleared, it might have triggered before. */ - ic->ic_clear(iv); + if (ic->ic_clear != NULL) + ic->ic_clear(iv); sx_xunlock(&intr_table_lock); return (0); } -- cgit v1.1