Hmm, x86 doesn't seem to support the NO_IRQ convention. This means
that portable code can't use it. Which in turn means that there's
no portable way for drivers to know whether they have been handed a
valid IRQ number (zero usually being valid). Double-plus ungood.
Signed-off-by: David Brownell <[email protected]>
---
I suspect this has been discussed before, but I can't find any
written resolution ...
include/asm-x86/irq.h | 4 ++++
1 file changed, 4 insertions(+)
--- a/include/asm-x86/irq.h 2008-06-22 16:36:43.000000000 -0700
+++ b/include/asm-x86/irq.h 2008-06-22 16:37:06.000000000 -0700
@@ -3,3 +3,7 @@
#else
# include "irq_64.h"
#endif
+
+#ifndef NO_IRQ
+#define NO_IRQ ((unsigned int)(-1))
+#endif
On Sun, 22 Jun 2008 19:53:18 -0700
David Brownell <[email protected]> wrote:
> Hmm, x86 doesn't seem to support the NO_IRQ convention. This means
> that portable code can't use it. Which in turn means that there's
> no portable way for drivers to know whether they have been handed a
> valid IRQ number (zero usually being valid). Double-plus ungood.
NAK. It was discussed before repeatedly as you suspected and settled by
Linus ultimately.
Zero is not a valid IRQ in the kernel mapping of things. If you have a
physical IRQ 0 remap it. That way you can write the more natural
if (dev->irq)
setup_for_irq(dev);
else
poll(dev);
type stuff.
NO_IRQ was intentionally removed from various platforms and really wants
kicking out of some others.
Alan
On Sun, 2008-06-22 at 19:53 -0700, David Brownell wrote:
> Hmm, x86 doesn't seem to support the NO_IRQ convention. This means
> that portable code can't use it. Which in turn means that there's
> no portable way for drivers to know whether they have been handed a
> valid IRQ number (zero usually being valid). Double-plus ungood.
>
> Signed-off-by: David Brownell <[email protected]>
> ---
> I suspect this has been discussed before, but I can't find any
> written resolution ...
>
> include/asm-x86/irq.h | 4 ++++
> 1 file changed, 4 insertions(+)
>
> --- a/include/asm-x86/irq.h 2008-06-22 16:36:43.000000000 -0700
> +++ b/include/asm-x86/irq.h 2008-06-22 16:37:06.000000000 -0700
> @@ -3,3 +3,7 @@
> #else
> # include "irq_64.h"
> #endif
> +
> +#ifndef NO_IRQ
> +#define NO_IRQ ((unsigned int)(-1))
> +#endif
NO_IRQ on x86 is 0
In fact, we explicitely changed powerpc to do the same :-) (It became
easy after I made all linux irqs be virtual, and dynamically mapped to
physical numbers).
I think Linus wants everybody to follow...
Cheers,
Ben.
On Monday 23 June 2008, Benjamin Herrenschmidt wrote:
> NO_IRQ on x86 is 0
There is no such #define for it.
And since zero is used for timer IRQs, it's not invalid.
On Monday 23 June 2008, Alan Cox wrote:
> Zero is not a valid IRQ in the kernel mapping of things.
That's counter-factual:
CPU0 CPU1
0: 42851354 6500253 IO-APIC-edge timer
1: 475459 45904 IO-APIC-edge i8042
8: 0 1 IO-APIC-edge rtc0
9: 135 18 IO-APIC-fasteoi acpi
12: 5232181 495206 IO-APIC-edge i8042
...
That's on x86. A quick survey of other boards around here
shows many that use IRQ 0 too.
I certainly agree it'd be convenient to be able to just test
for IRQ being nonzero. Presumably only one driver would ever
end up using IRQ 0 on x86, so other drivers could ignore the
fact that testing for nonzero would mean "not the timer irq"
rather than "no irq assigned".
- Dave
On Mon, Jun 23, 2008 at 10:08:23AM +0100, Alan Cox wrote:
>
> Zero is not a valid IRQ in the kernel mapping of things. If you have a
> physical IRQ 0 remap it.
I'm confused. On my Thinkpad with kernel 2.6.25 I get:
$ cat /proc/interrupts
CPU0
0: 4398925 XT-PIC-XT timer
1: 287065 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
...
Johannes
On Mon, 23 Jun 2008 04:29:36 -0700
David Brownell <[email protected]> wrote:
> On Monday 23 June 2008, Alan Cox wrote:
> > Zero is not a valid IRQ in the kernel mapping of things.
>
> That's counter-factual:
There are historical reasons for the timer tick (which isn't visible
outside arch code) being 0 on x86.
> I certainly agree it'd be convenient to be able to just test
> for IRQ being nonzero.
0 means "no IRQ" in things like dev->irq. Lots of driver code assumes
this and it has been decreed 'correct'.
Alan
On Mon, 2008-06-23 at 04:28 -0700, David Brownell wrote:
> On Monday 23 June 2008, Benjamin Herrenschmidt wrote:
> > NO_IRQ on x86 is 0
>
> There is no such #define for it.
> And since zero is used for timer IRQs, it's not invalid.
I'll refer you to past discussions with Linus here. 0 is invalid to
drivers for all intend and purposes.
Cheers,
Ben.
David Brownell wrote:
> On Monday 23 June 2008, Benjamin Herrenschmidt wrote:
>> NO_IRQ on x86 is 0
>
> There is no such #define for it.
> And since zero is used for timer IRQs, it's not invalid.
As far as drivers are concerned it is. IRQ 0 is only used by
architecture-specific code and is not sharable, so drivers need not be
concerned about it.
On Monday 23 June 2008, Robert Hancock wrote:
> IRQ 0 is only used by
> architecture-specific code and is not sharable,
That seems to be the consensus, and it does reflect
how it's used on all architectures I happen to have
seen it in use.
Leaving the question then of what should happen to
the existing NO_IRQ code ... none of the declarations
seems to have a comment "deprecated, don't use this"
and most of the defined values are nonzero.
Some docs appear to be missing.
> Leaving the question then of what should happen to
> the existing NO_IRQ code ... none of the declarations
> seems to have a comment "deprecated, don't use this"
> and most of the defined values are nonzero.
Send patches to the arch maintainers in question.
Alan