Re: [PATCH 4/5] Centralise NO_IRQ definition

[Linus Torvalds]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/