Re: [PATCH 4/5] Centralise NO_IRQ definition

[Matthew Wilcox <matthew@wil.cx>]

On Mon, Nov 21, 2005 at 10:55:24AM -0800, Linus Torvalds wrote:
> Quite frankly, if we change [PCI_]NO_IRQ to -1, there's almost certainly 
> going to be a lot of drivers breaking.

There's only one driver using NO_IRQ today (outside of architectures
which define NO_IRQ to -1, that is).  So *this* series of patches should
break nothing.  The next series of patches should find all the PCI
drivers assuming dev->irq == 0 means no interrupt, and then we try to
break drivers by getting rid of PCI_NO_IRQ.

> This is not theory: a _lot_ of real-life PCI devices very much think that 
> irq 0 means "disabled". Not even just in drivers - in actual _hardware_. 
> When you write 0 to the irq number for irq routers, they disable that 
> line. So the "zero as NO_IRQ" is more than just a "several drivers think 
> that is how it is", it's how a lot of hardware actually works.

That's a common misreading of the PCI spec -- it actually says the
opposite.  Interrupt Pin works as you've described.  But what we're
concerned with is Interrupt Line, and PCI 2.3 has the following to say
in a footnote:

	43 For x86 based PCs, the values in this register correspond to
	IRQ numbers (0-15) of the standard dual 8259 configuration. The
	value 255 is defined as meaning "unknown" or "no connection" to
	the interrupt controller. Values between 15 and 254 are reserved.

It's just that Linux doesn't bother to read Interrupt Line if Interrupt
Pin is 0, and thus leaves the interrupt value at 0 (since the struct was
memset).

Really, this patch brings x86 back into compliance with what the
BIOS does ;-)