On Tue, 22 Nov 2005, Paul Mackerras wrote:
>
> First, are you talking about the interrupt pin register or the
> interrupt line register?
Interrupt line. The interrupt pin is totally separate.
> Secondly, I would say that any driver that looks at either of those
> registers is broken. Drivers should be looking at dev->irq, which is
> set up by platform code, and may be quite different from what is in
> the interrupt line register.
But that's part of the POINT, Paul.
The platform code needs to set up something in dev->irq. And we have
_always_ had "dev->irq == 0" meaning "no irq".
So if PCI irq (the interrupt line register or whatever) 0 means something
for you on PPC, then BY DEFINITION you should not have translated it into
"dev->irq". But PPC did. Tough. Don't blame that mistake on me, or try to
force that mistake on other architectures.
The fact that PPC screwed that up is a PPC problem, and it's a PPC problem
from the very beginning, because the "dev->irq" value doesn't have to
match the PCI irq at all.
On sparc, for example, "dev->irq" used to be some random cookie, if I
remember correctly. But "0" still meant "unallocated".
So face it. PPC screwed up, and if it had just followed what the
"dev->irq" meant on the regular x86 platforms, it wouldn't have needed
that NO_IRQ in the first place.
The whole notion of needing "NO_IRQ" is broken. The way to test for not
having an irq is "!dev->irq". Any architecture that uses NO_IRQ is just a
bug waiting to happen, for any number of drivers. And for no good reason.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
