[PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
Alan Cox
alan at lxorguk.ukuu.org.uk
Tue Dec 6 22:05:54 EST 2011
> 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
More information about the devicetree-discuss
mailing list