Re: First steps towards making NO_IRQ a generic concept

[Ingo Molnar <mingo@elte.hu>]

* Matthew Wilcox <matthew@wil.cx> wrote:

> 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.

ok, understood. I'm wondering, why is there any need to do a PCI_NO_IRQ?  
Why not just a generic NO_IRQ. It's not like we can or want to make them 
different in the future. The interrupt vector number is a generic thing 
that attaches to the platform via request_irq() - there is nothing 'PCI' 
about it. So the PCI layer shouldnt pretend it has its own IRQ 
abstraction - the two are forcibly joined. The same goes for 
pci_valid_irq() - we should only have valid_irq(). Am i missing 
anything?

> > 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.

ok. Your transition path looks safe to me.

	Ingo