Messages in this thread | | | Date | Mon, 21 Nov 2005 17:26:08 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [PATCH 4/5] Centralise NO_IRQ definition |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |