Add NO_IRQ to all architectures
RFC 1/1 Add NO_IRQ to all architectures
Hi !
Here'd a patch adding a definition of NO_IRQ to all archs include/asm-*/irq.h.
This patch currently defines it to (-1) for all archs. IRQ numbers are randomly stored in int's, unsigned int's, or all sort of things all over the kernel, but that shouldn't be a problem in most cases. NO_IRQ is mostly to be used within a given driver, to identify a device for which it has no IRQ assigned. This concerns relatively few drivers, like 8250 or IDE.
At this point, I do _not_ intend to fix the probe_irq_*() API to return NO_IRQ instead of 0, that could be done in a second step (or x86 NO_IRQ could simply be defined to be 0 ...), but I will fix IDE in a subsequent patch.
It would be nice though if things could slowly get fixed to deal with it in a better way.
include/asm-ppc/irq.h +2 -0
@@ -6,6 +6,8 @@#include <asm/machdep.h> /* ppc_md */ #include <asm/atomic.h> +#define NO_IRQ (-1) +/* * These constants are used for passing information about interrupt * signal polarity and level/edge sensing to the low-level PIC chip
include/asm-sparc64/irq.h +3 -0
@@ -16,6 +16,9 @@#include <asm/pil.h> #include <asm/ptrace.h> + +#define NO_IRQ (-1) +/* You should not mess with this directly. That's the job of irq.c. * * If you make changes here, please update hand coded assembler of
include/asm-m68k/irq.h +2 -0
@@ -10,6 +10,8 @@#define SYS_IRQS 8 +#define NO_IRQ (-1) +/* * This should be the same as the max(NUM_X_SOURCES) for all the * different m68k hosts compiled into the kernel.
include/asm-sparc/irq.h +2 -0
@@ -15,6 +15,8 @@#include <asm/system.h> /* For SUN4M_NCPUS */ #include <asm/btfixup.h> +#define NO_IRQ (-1) +#define __irq_ino (irq) irq#define __irq_pil (irq) irq BTFIXUPDEF_CALL(char *, __irq_itoa, unsigned int)
include/asm-mips/irq.h +2 -0
@@ -13,6 +13,8 @@#include <linux/linkage.h> #include <irq.h> +#define NO_IRQ (-1) +#ifdef CONFIG_I8259 static inline int irq_canonicalize (int irq) {
include/asm-s390/irq.h +2 -0
@@ -4,6 +4,8 @@#ifdef __KERNEL__#include <linux/hardirq.h> +#define NO_IRQ (-1) +/* * the definition of irqs has changed in 2.5.46: * NR_IRQS is no longer the number of i/o
include/asm-cris/irq.h +2 -0
@@ -3,6 +3,8 @@#include <asm/arch/irq.h> +#define NO_IRQ (-1) +extern __inline__int irq_canonicalize (int irq) {return irq;
include/asm-v850/irq.h +2 -0
@@ -16,6 +16,8 @@#include <asm/machdep.h> +#define NO_IRQ (-1) +/* Default NUM_MACH_IRQS. */ #ifndef NUM_MACH_IRQS #define NUM_MACH_IRQS NUM_CPU_IRQS
include/asm-m68knommu/irq.h +2 -0
@@ -5,6 +5,8 @@#include <linux/interrupt.h> #include <asm/ptrace.h> +#define NO_IRQ (-1) +#ifdef CONFIG_COLDFIRE /* * On the ColdFire we keep track of all vectors. That way drivers
include/asm-alpha/irq.h +2 -0
@@ -10,6 +10,8 @@#include <linux/linkage.h> #include <linux/config.h> +#define NO_IRQ (-1) +#if defined(CONFIG_ALPHA_GENERIC )/* Here NR_IRQS is not exact, but rather an upper bound. This is used
include/asm-sh/irq.h +2 -0
@@ -15,6 +15,8 @@#include <asm/machvec.h> #include <asm/ptrace.h> /* for pt_regs */ +#define NO_IRQ (-1) +#if defined(CONFIG_SH_HP600 ) || \ defined(CONFIG_SH_RTS7751R2D ) || \ defined(CONFIG_SH_HS7751RVOIP )
include/asm-ia64/irq.h +1 -0
@@ -13,6 +13,7 @@#define NR_IRQS 256#define NR_IRQ_VECTORS NR_IRQS +#define NO_IRQ (-1)static __inline__int irq_canonicalize (int irq)
include/asm-i386/irq.h +2 -0
@@ -16,6 +16,8 @@#include "irq_vectors.h" #include <asm/thread_info.h> +#define NO_IRQ (-1) +static __inline__int irq_canonicalize (int irq) {return ((irq ==2 ) ?9 : irq);
include/asm-parisc/irq.h +1 -0
@@ -19,6 +19,7 @@#include <linux/interrupt.h> #include <linux/config.h> +#define NO_IRQ (-1)#define CPU_IRQ_REGION 1#define TIMER_IRQ (IRQ_FROM_REGION(CPU_IRQ_REGION) | 0)
include/asm-x86_64/irq.h +2 -0
@@ -10,6 +10,8 @@* <[email protected]> */ +#define NO_IRQ (-1) +#define TIMER_IRQ 0/*
include/asm-sh64/irq.h +2 -0
@@ -14,6 +14,8 @@#include <linux/config.h> +#define NO_IRQ (-1) +/* * Encoded IRQs are not considered worth to be supported. * Main reason is that there's no per-encoded-interrupt
include/asm-m32r/irq.h +2 -0
@@ -5,6 +5,8 @@#include <linux/config.h> +#define NO_IRQ (-1) +#if defined(CONFIG_PLAT_M32700UT_Alpha) || defined(CONFIG_PLAT_USRV )/* * IRQ definitions for M32700UT
include/asm-h8300/irq.h +2 -0
@@ -3,6 +3,8 @@#include <asm/ptrace.h> +#define NO_IRQ (-1) +#if defined(__H8300H__)#define NR_IRQS 64#define EXT_IRQ0 12
Quoted 1 line · Benjamin Herrenschmidt
Here'd a patch adding a definition of
NO_IRQto all archs
include/asm-*/irq.h. This patch currently defines it to (-1) for all
Quoted 11 lines
archs. IRQ numbers are randomly stored in int's, unsigned int's, or all sort of things all over the kernel, but that shouldn't be a problem in most cases.
NO_IRQis mostly to be used within a given driver, to identify a device for which it has no IRQ assigned. This concerns relatively few drivers, like 8250 or IDE.
At this point, I do _not_ intend to fix the probe_irq_*() API to returnNO_IRQinstead of 0, that could be done in a second step (or x86NO_IRQcould simply be defined to be 0 ...), but I will fix IDE in a subsequent patch.
It would be nice though if things could slowly get fixed to deal with it in a better way.
Maybe wrapping the numbers in a struct for strict typechecking given some config option, eventually making it mandatory once enough drivers are swept would make sense.
-- wli
Quoted 2 lines · Benjamin Herrenschmidt
Here'd a patch adding a definition of
NO_IRQto all archsinclude/asm-*/irq.h.
..and is there any reason to make it arch-specific?
iow, I really can't imagine it not being ok to just have a global
#define NO_IRQ (-1)
in one place, rather than in every arch.
Linus
Quoted 5 lines · Linus Torvalds
Quoted 2 lines · Benjamin Herrenschmidt
Here'd a patch adding a definition of
NO_IRQto all archsinclude/asm-*/irq.h.
Quoted 7 lines
..and is there any reason to make it arch-specific?
iow, I really can't imagine it not being ok to just have a global
#define NO_IRQ (-1)in one place, rather than in every arch.
Hehe... just after I went through all include/asm-*/... :)
Well, the reason I did it that way is that I wasn't sure an arch wouldn't want to revert to 0 ... like x86 to be more "backward compatible" or to better match what probe_irq_* does ...
Note to Willy: In the long run, the irq number should indeed be a typedef, it would be nice indeed to hide it in a structure, with some ISA_TO_IRQ and IRQ_TO_ISA for drivers who care about legacy numbers maybe ?
Ben.
Quoted 8 lines · Benjamin Herrenschmidt
Hehe... just after I went through all
include/asm-*/... :) Well, the reason I did it that way is that I wasn't sure an arch wouldn't want to revert to 0 ... like x86 to be more "backward compatible" or to better match what probe_irq_* does ... Note to Willy: In the long run, the irq number should indeed be a typedef, it would be nice indeed to hide it in a structure, with someISA_TO_IRQandIRQ_TO_ISAfor drivers who care about legacy numbers maybe ?
Justin case there was any confusion, this was William Irwin, not Matthew Wilcox.
-- wli
Quoted 3 lines · Benjamin Herrenschmidt
Well, the reason I did it that way is that I wasn't sure an arch wouldn't want to revert to 0 ... like x86 to be more "backward compatible" or to better match what probe_irq_* does ...
Surely that's a reason to put it in include/linux/ and _force_ it to -1, to prevent them from doing such a thing? We particularly don't want x86 doing this, because most people only test their drivers on x86.
Quoted 4 lines
Note to Willy: In the long run, the irq number should indeed be a typedef, it would be nice indeed to hide it in a structure, with some
ISA_TO_IRQandIRQ_TO_ISAfor drivers who care about legacy numbers maybe ?
Sounds like a very good idea. Eventually, perhaps, we can acknowledge that interrupts are a tree, and that interrupt controllers can be hot-plugged. :)
Signature · 1 line
dwmw2