Re: [RFC] disable_irq()/enable_irq() semantics and ide-probe.c

[Russell King <rmk@arm.linux.org.uk>]

On Wed, Oct 08, 2003 at 07:53:36PM -0700, Linus Torvalds wrote:
> On Thu, 9 Oct 2003 viro@parcelfarce.linux.theplanet.co.uk wrote:
> > ObOtherFun:  There's another bogosity in quoted ide-probe.c code, according
> > to dwmw2 - he says that there are PCI IDE cards that get IRQ 0, so the
> > test for hwif->irq is b0rken.  We probably should stop overloading
> > ->irq == 0 for "none given", but I'm not sure that we *have* a value
> > that would never be used as an IRQ number on all platforms...
> 
> The BIOS defines irq 0 in the PCI config space to be "no irq" as far as I
> know, and on all PC platforms I've ever heard of it's not a usable irq for
> generic PCI devices (it's wired to the timer thing). 
> 
> All PCI routing chipsets I know about also make "irq0" mean "disabled". 

Correct for x86.  For other architectures, it many not be so.  On ARM for
example, it is quite normal for IRQ0 to be used.  Hopefully it'll be
something which generic code won't see, but that isn't always true.
Someone else might actually follow the PCI specs and use "255" to mean
"no irq" on their PCI bus.

Irregardless of all that, ARM has always had the following in asm/irq.h:

/*
 * Use this value to indicate lack of interrupt
 * capability
 */
#ifndef NO_IRQ
#define NO_IRQ  ((unsigned int)(-1))
#endif

and each time this topic comes up, I always suggest that this idea needs
to be propagated to the rest of the kernel - a method by which an interrupt
number can be tested to check whether it is real.  I don't particularly
care if its a constant, or a function-like thing, eg for x86:

#define no_irq(irq) ((irq) == 0)

-- 
Russell King (rmk@arm.linux.org.uk)	http://www.arm.linux.org.uk/personal/
      Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
      maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                      2.6 Serial core