> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
