[PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
Russell King - ARM Linux
linux at arm.linux.org.uk
Tue Dec 6 22:25:45 EST 2011
On Tue, Dec 06, 2011 at 11:05:54AM +0000, Alan Cox wrote:
> > 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.
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.
More information about the devicetree-discuss
mailing list