Messages in this thread |  | | Subject | Re: [PATCH 4/5] Centralise NO_IRQ definition | From | David Woodhouse <> | Date | Tue, 22 Nov 2005 23:58:34 +0000 |
| |
On Tue, 2005-11-22 at 11:21 -0800, Linus Torvalds wrote: > Of _course_ "irq0" is a valid irq. On PC's, it's usually the timer > interrupt. > > It's the "dev->irq" _cookie_ zero that means it is does not have an irq. > > If you have a physical "irq 0" that is bound to a device, it needs a > cookie, and that cookie can't be 0, because that means the device has no > interrupt. > > How hard is that to understand? Why do people mix these up?
Mostly I'd suggest that people mix them up because you've only just made up this 'cookie' nonsense, and the number we store in dev->irq has always been just the irq number -- at least on all but SPARC, which was always 'special'. That's precisely _why_ we have a mix of 'int' and 'long' and other types in which we store it, as you've said. It's never been considered a 'cookie'.
But turning it into a cookie makes enough sense, I suppose, as long as we stop confusing it with irq 'numbers' -- and that includes banning anyone from printing it with '%d'.
I'm inclined to agree with David's suggestion of making it a pointer. Then it can point to a structure which is part a proper _tree_ of interrupts which actually resembles reality. And SPARC can stop being a special (and probably saner) case. And all the mess which platforms have with assigning interrupt 'number' ranges for various PICs can go away. And hotplug interrupt controllers (it happens, on CardBus or with hotplug PCI) can work sanely. But Matthew still can't have his pony.
Yes, you still need a mapping at _setup_ time from stuff like isapnp and OpenFirmware interrupt numbers to the appropriate 'cookie', but that's not so hard.
-- dwmw2
- 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/
|  |