[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwiLp1z+2mzkrFsid1WZQ0TQkcn8F2E6NL_AVR+m1fZ2w@mail.gmail.com>
Date: Wed, 9 May 2012 10:51:06 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Mikulas Patocka <mpatocka@...hat.com>
Cc: Alan Cox <alan@...rguk.ukuu.org.uk>,
"James E.J. Bottomley" <jejb@...isc-linux.org>,
Helge Deller <deller@....de>, linux-parisc@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Fix compile failure on PA-RISC
On Tue, May 8, 2012 at 8:20 PM, Mikulas Patocka <mpatocka@...hat.com> wrote:
>>
>> Switching it to zero and testing that things still work would be appreciated.
>
> It works, but there is plenty of interrupt controllers on PC-RISC and I
> can only test it on C8000 with IO-SAPIC. I don't know if irq 0 is used on
> some PA-RISC interrupt controller. It would be best if James Bottomley
> tests it on his set of machines.
Heh. It sounds like we have more PA-RISC machines than we have actual users.
> And what about x86? --- irq 0 is used for timer and there is
> void __init setup_default_timer_irq(void)
> {
> setup_irq(0, &irq0);
> }
> in arch/x86/kernel/time.c.
That's fine. There's no "irq" variable associated with it that people
can test. No driver will ever see an irq number of zero, no dynamic
irq code will ever see the zero.
So x86 rules have always been that the way drivers etc test for irq
existence has always been "irq 0 means no irq". Despite the fact that
it internally uses irq0 for its own nefarious uses.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists