On Tue, Oct 26, 2010 at 11:18 PM, David Daney <ddaney@xxxxxxxxxxxxxxxxxx> wrote: > On 10/14/2010 06:27 PM, Grant Likely wrote: >> >> On Thu, Oct 14, 2010 at 3:02 PM, David Daney<ddaney@xxxxxxxxxxxxxxxxxx> >> wrote: > > [...] >>> >>> +#define NO_IRQ UINT_MAX >> >> Really? The verdict came down a long time ago that 0 is to be the >> value that means no irq, and only a few architectures still define >> NO_IRQ as -1. It is assumed that the architectures which do not >> define NO_IRQ use 0 as the invalid value. Mostly notably x86 does not >> define NO_IRQ, and Linus nack'd the patch to add it. >> > > I was not part of that discussion. > > I would however note, that all the irq functions return unsigned, so a value > of -1 is meaningless. Also my understanding is that 8259 based systems use > the values of 0 - 15 as the interrupt numbers, making 0 unavailable for use > as NO_IRQ. This is an old discussion which has been debated thoroughly and ultimately resolved by Linus[1]. NO_IRQ is in the (slow) process of being removed entirely. It is worth reading the entire thread for background. [1] http://lkml.org/lkml/2005/11/21/200 An irq value of 0 means no irq, and the correct cross-platform test is "if (!irq)". Note that this is the /linux/ irq number, not the hardware irq number. Of course interrupt controller hardware may define an interrupt number zero, it must not be mapped to linux irq number zero. As you note, 8259 systems do define an irq number 0 which is mapped to the timer, but it is not exported to driver code. If an architecture wants to use irq 0 directly, then it should be contained in the arch code. g.
