[Top] [All Lists]

Re: [PATCH] MIPS: Add some irq definitins required by OF

To: David Daney <>
Subject: Re: [PATCH] MIPS: Add some irq definitins required by OF
From: Grant Likely <>
Date: Wed, 27 Oct 2010 09:10:40 +0100
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <>
On Tue, Oct 26, 2010 at 11:18 PM, David Daney <> wrote:
> On 10/14/2010 06:27 PM, Grant Likely wrote:
>> On Thu, Oct 14, 2010 at 3:02 PM, David Daney<>
>>  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


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


<Prev in Thread] Current Thread [Next in Thread>