[PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Russell King - ARM Linux <hidden>
Date: 2011-12-06 11:26:23
Also in:
linux-devicetree, linux-ide, linux-next, lkml
On Tue, Dec 06, 2011 at 11:05:54AM +0000, Alan Cox wrote:
quoted
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.quoted
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.quoted
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.quoted
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.
For the platforms I care about, it probably won't break. For those which do break, it's a matter of fixing their include/mach/irqs.h and the code in their irqchips to convert the IRQ number to the correct bitmask for the register. However, I have suggested in the past that new platforms _should_ avoid not just IRQ0 but IRQ0-15 (for a completely different reason to that of 'IRQ0 means no IRQ'.) But such comments just get ignored, so I just don't see the point in doing anything about this. If people experience breakage, so be it. I too will have little sympathy but not for the same reason.