Even better.  Avoid the first 16 IRQ numbers altogether - so that ISA
drivers which have these numbers hard-encoded in them will see failures
if they're expecting standard ISA IRQ numbering.

The ISA bus space is non-discoverable so that doesn't make any sense.

But.. let's make one thing clear: Alan Cox and Linus have been going on
about how IRQ0 should not be used.  Let's be crystal clear: even x86
uses IRQ0.  It happens to be the PIC timer, and that gets claimed early
on during the x86 boot.  So please don't tell me that x86 avoids IRQ0.
It doesn't.  It just happens that x86 never shows IRQ0 to anything but
the i8253 PIC driver.

x86 has an internal invisible IRQ 0 on some platforms. It's never exposed
beyond the arch code.

So lets see how x86 squeels if we make the i8253 PIC driver reject IRQ0.
I bet that there'd be absolute fury at such a suggestion.

Actually it would be about ten minutes work to remap it to some other
number that isn't used. It never goes via request_irq or via any core or
driver layer code however.

In the ARM case the same is going to be true. If you have IRQ 0 plumbing
that only goes internally in the arch/arm code - eg an ARM with IRQ 0
wired to something totally arch specific and non-driver then it's not
going to break and like the internals of x86 doesn't matter.

When x86 sorts this out, there _might_ be some more motivation to take
such comments seriously.  Until then it's more like a joke.

Pity you feel that way, but if ARM wants to continue to break more and
more as we clean up NO_IRQ for everything else that's your privilege, but
don't expect any sympathy.

Alan