Re: [PATCH 4/5] Centralise NO_IRQ definition
From: Linus Torvalds
Date: Mon Nov 21 2005 - 13:55:34 EST
On Mon, 21 Nov 2005, Matthew Wilcox wrote:
> On Mon, Nov 21, 2005 at 11:12:36AM +0000, David Howells wrote:
> > Matthew Wilcox <matthew@xxxxxx> 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
Which means that I'd _much_ prefer to other architectures to just follow
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
#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
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/