[patch] x86 supports NO_IRQ convention

[patch] x86 supports NO_IRQ convention

[David Brownell]

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 <dbrownell@users.sourceforge.net>
---
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

Re: [patch] x86 supports NO_IRQ convention

[Alan Cox]

On Sun, 22 Jun 2008 19:53:18 -0700
David Brownell <david-b@pacbell.net> 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

Re: [patch] x86 supports NO_IRQ convention

[David Brownell]

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

Re: [patch] x86 supports NO_IRQ convention

[Alan Cox]

On Mon, 23 Jun 2008 04:29:36 -0700
David Brownell <david-b@pacbell.net> 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

Re: [patch] x86 supports NO_IRQ convention

[Johannes Stezenbach]

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

Re: [patch] x86 supports NO_IRQ convention

[Benjamin Herrenschmidt]

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 <dbrownell@users.sourceforge.net>
> ---
> 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.

Re: [patch] x86 supports NO_IRQ convention

[David Brownell]

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.

Re: [patch] x86 supports NO_IRQ convention

[Benjamin Herrenschmidt]

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.

Re: [patch] x86 supports NO_IRQ convention

[Robert Hancock]

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.

Re: [patch] x86 supports NO_IRQ convention

[David Brownell]

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.

Re: [patch] x86 supports NO_IRQ convention

[Alan Cox]

> 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