Re: First steps towards making NO_IRQ a generic concept

[Matthew Wilcox <matthew@wil.cx>]

On Thu, Nov 03, 2005 at 04:44:39PM +0100, Ingo Molnar wrote:
> > +	if (irq >= NR_IRQS)
> > +		return;
> 
> hm, why not start with the -1 value for PCI_NO_IRQ, instead of 0:
> 
> > +#define PCI_NO_IRQ             0
> 
> and be done with it.

There's a number of drivers which check "if (!irq) ...".  For example:

drivers/net/3c523.c:            if ((irq && irq != dev->irq) || 
drivers/net/atarilance.c:               if (!irq) {
drivers/net/cs89x0.c:           if (!dev->irq)
drivers/net/depca.c:                    if (!dev->irq) {
drivers/net/eexpress.c: if (!dev->irq || !irqrmap[dev->irq])
drivers/net/ewrk3.c:                            if (!dev->irq) {
drivers/net/ibmlana.c:          return (base != 0 || irq != 0) ? -ENXIO
: -ENODE
drivers/net/lasi_82596.c:       if (!dev->irq) {
drivers/net/ne-h8300.c: if (! dev->irq) {
drivers/net/ne.c:       if (! dev->irq) {
drivers/net/ni52.c:             if(!dev->irq)
drivers/net/ni65.c:                     if(!dev->irq)
drivers/net/pcnet32.c:  if (!dev->irq) {

... and that's just drivers/net, and that doesn't include other ways
for checking if irq is not 0, and doesn't include irqs referred to
under different names not including the string 'irq'.  Against that,
I know not all of these are PCI drivers.  So we need to spend some time
checking drivers for this assumption.

We also need to figure out what to do with non-PCI drivers.  Some of
them need more work than others to work with a -1 NO_IRQ.  There's also
plenty of janitorial work with people misusing the probe_irq_off()
interface.

> > - Move the definition of NO_IRQ from asm directories to 
> >   <linux/hardirq.h>. Individual architectures can still override it if 
> >   they want to, but all existing definitions were -1.
> 
> we shouldnt make it overridable just for the sake of it. If all arches 
> were fine with -1, it should be the generic value and there's no 
> override.

Fine with me.  I can take out the ifndef.

> plus, shouldnt this go into -mm first, since it clearly affects some 
> drivers? Why into Linus' tree immediately?

With the way I'm staging it, it shouldn't affect drivers.  The only
exception was the pcmcia driver that defined its own NO_IRQ macro.  So I
converted that one to the new preferred way to check the irq is unset.