Re: [PATCH 4/5] Centralise NO_IRQ definition

[Linus Torvalds <torvalds@osdl.org>]

On Mon, 21 Nov 2005, Matthew Wilcox wrote:
>
> On Mon, Nov 21, 2005 at 11:12:36AM +0000, David Howells wrote:
> > Matthew Wilcox <matthew@wil.cx> wrote:
> > 
> > > +#define NO_IRQ			((unsigned int)(-1))
> > 
> > Should this be wrapped with #ifndef?
> 
> *sigh*.  The one piece of feedback I got on the last series was from
> Ingo, and he asked that I *not* wrap it with ifndef.  So, no.

Quite frankly, if we change [PCI_]NO_IRQ to -1, there's almost certainly 
going to be a lot of drivers breaking.

On x86, 0 has been the lack of IRQ since basically forever, in one form or 
another (for devices, that is - there _is_ a timer irq 0, but that's set 
up separately).

Which means that I'd _much_ prefer to other architectures to just follow 
suit.

So for an architecture where irq0 is a valid physical interrupt for a 
device, why not just translate that "real irq 0" into some other thing? 
Much less likely to break anything.

In fact, it could be as simple as setting the high bit for any valid 
interrupt, and then just masking it out in request_irq() and friends. Do 
something like

	#define PCI_IRQ_VALID_MASK	(1u << 31)

and then if the physical irq is 0, just or in that VALID mask, turning the 
interrupt into a non-zero, and then when registering it, just and it away 
again..

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.

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/