All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: davidm@hpl.hp.com
Cc: linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [2.6 patch] IA64 irq.c: remove CONFIG_X86 code
Date: Fri, 19 Nov 2004 00:19:15 +0000	[thread overview]
Message-ID: <20041119001915.GL4943@stusta.de> (raw)

I don't see hos this code could ever be used.

Am I correct or did I miss something?


diffstat output:
 arch/ia64/kernel/irq.c |   33 ---------------------------------
 1 files changed, 33 deletions(-)


Signed-off-by: Adrian Bunk <bunk@fs.tum.de>

--- linux-2.6.10-rc2-mm2-full/arch/ia64/kernel/irq.c.old	2004-11-19 01:14:22.000000000 +0100
+++ linux-2.6.10-rc2-mm2-full/arch/ia64/kernel/irq.c	2004-11-19 01:16:31.000000000 +0100
@@ -132,23 +132,7 @@
  * each architecture has to answer this themselves, it doesn't deserve
  * a generic callback i think.
  */
-#ifdef CONFIG_X86
-	printk(KERN_ERR "unexpected IRQ trap at vector %02x\n", irq);
-#ifdef CONFIG_X86_LOCAL_APIC
-	/*
-	 * Currently unexpected vectors happen only on SMP and APIC.
-	 * We _must_ ack these because every local APIC has only N
-	 * irq slots per priority level, and a 'hanging, unacked' IRQ
-	 * holds up an irq slot - in excessive cases (when multiple
-	 * unexpected vectors occur) that might lock up the APIC
-	 * completely.
-	 */
-	ack_APIC_irq();
-#endif
-#endif
-#ifdef CONFIG_IA64
 	printk(KERN_ERR "Unexpected irq vector 0x%x on CPU %u!\n", irq, smp_processor_id());
-#endif
 }
 
 /* startup is the same as "enable", shutdown is same as "disable" */
@@ -166,11 +150,6 @@
 };
 
 atomic_t irq_err_count;
-#ifdef CONFIG_X86_IO_APIC
-#ifdef APIC_MISMATCH_DEBUG
-atomic_t irq_mis_count;
-#endif
-#endif
 
 /*
  * Generic, controller-independent functions:
@@ -220,19 +199,7 @@
 			if (cpu_online(j))
 				seq_printf(p, "%10u ", nmi_count(j));
 		seq_putc(p, '\n');
-#ifdef CONFIG_X86_LOCAL_APIC
-		seq_puts(p, "LOC: ");
-		for (j = 0; j < NR_CPUS; j++)
-			if (cpu_online(j))
-				seq_printf(p, "%10u ", irq_stat[j].apic_timer_irqs);
-		seq_putc(p, '\n');
-#endif
 		seq_printf(p, "ERR: %10u\n", atomic_read(&irq_err_count));
-#ifdef CONFIG_X86_IO_APIC
-#ifdef APIC_MISMATCH_DEBUG
-		seq_printf(p, "MIS: %10u\n", atomic_read(&irq_mis_count));
-#endif
-#endif
 	}
 	return 0;
 }

WARNING: multiple messages have this Message-ID (diff)
From: Adrian Bunk <bunk@stusta.de>
To: davidm@hpl.hp.com
Cc: linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [2.6 patch] IA64 irq.c: remove CONFIG_X86 code
Date: Fri, 19 Nov 2004 01:19:15 +0100	[thread overview]
Message-ID: <20041119001915.GL4943@stusta.de> (raw)

I don't see hos this code could ever be used.

Am I correct or did I miss something?


diffstat output:
 arch/ia64/kernel/irq.c |   33 ---------------------------------
 1 files changed, 33 deletions(-)


Signed-off-by: Adrian Bunk <bunk@fs.tum.de>

--- linux-2.6.10-rc2-mm2-full/arch/ia64/kernel/irq.c.old	2004-11-19 01:14:22.000000000 +0100
+++ linux-2.6.10-rc2-mm2-full/arch/ia64/kernel/irq.c	2004-11-19 01:16:31.000000000 +0100
@@ -132,23 +132,7 @@
  * each architecture has to answer this themselves, it doesn't deserve
  * a generic callback i think.
  */
-#ifdef CONFIG_X86
-	printk(KERN_ERR "unexpected IRQ trap at vector %02x\n", irq);
-#ifdef CONFIG_X86_LOCAL_APIC
-	/*
-	 * Currently unexpected vectors happen only on SMP and APIC.
-	 * We _must_ ack these because every local APIC has only N
-	 * irq slots per priority level, and a 'hanging, unacked' IRQ
-	 * holds up an irq slot - in excessive cases (when multiple
-	 * unexpected vectors occur) that might lock up the APIC
-	 * completely.
-	 */
-	ack_APIC_irq();
-#endif
-#endif
-#ifdef CONFIG_IA64
 	printk(KERN_ERR "Unexpected irq vector 0x%x on CPU %u!\n", irq, smp_processor_id());
-#endif
 }
 
 /* startup is the same as "enable", shutdown is same as "disable" */
@@ -166,11 +150,6 @@
 };
 
 atomic_t irq_err_count;
-#ifdef CONFIG_X86_IO_APIC
-#ifdef APIC_MISMATCH_DEBUG
-atomic_t irq_mis_count;
-#endif
-#endif
 
 /*
  * Generic, controller-independent functions:
@@ -220,19 +199,7 @@
 			if (cpu_online(j))
 				seq_printf(p, "%10u ", nmi_count(j));
 		seq_putc(p, '\n');
-#ifdef CONFIG_X86_LOCAL_APIC
-		seq_puts(p, "LOC: ");
-		for (j = 0; j < NR_CPUS; j++)
-			if (cpu_online(j))
-				seq_printf(p, "%10u ", irq_stat[j].apic_timer_irqs);
-		seq_putc(p, '\n');
-#endif
 		seq_printf(p, "ERR: %10u\n", atomic_read(&irq_err_count));
-#ifdef CONFIG_X86_IO_APIC
-#ifdef APIC_MISMATCH_DEBUG
-		seq_printf(p, "MIS: %10u\n", atomic_read(&irq_mis_count));
-#endif
-#endif
 	}
 	return 0;
 }

             reply	other threads:[~2004-11-19  0:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-19  0:19 Adrian Bunk [this message]
2004-11-19  0:19 ` [2.6 patch] IA64 irq.c: remove CONFIG_X86 code Adrian Bunk
2004-11-19  6:42 ` Luck, Tony
2004-11-19  6:42   ` Luck, Tony

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041119001915.GL4943@stusta.de \
    --to=bunk@stusta.de \
    --cc=davidm@hpl.hp.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.