Messages in this thread | | | Date | Thu, 24 Apr 2008 08:16:53 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [git patch] free_irq() fixes |
| |
On Thu, 24 Apr 2008, Jeff Garzik wrote: > > Honestly, one thing I was thinking was perhaps a change from > > irqreturn_t foo_handler(int irq, void *dev_id) > to > irqreturn_t foo_handler(struct irq_info *ii, void *dev_id) > > which would IMO make the first parameter useful again, by enabling passing of > information like MSI message info, or more flexible platform-specific irq info > that a platform driver may want. Or direct access to irq_desc or irq_chip > info.
So I *really* hate that idea. It's much *much* worse than what we have now.
Why?
The absolutely _only_ piece of reliably information we have that is architecture- and irq-controller neutral is the exact information we pass in to "request_irq()". That is: irq number, the name, and the device cookie thing. Nothing more.
And of the three things, they have the following pattern:
- "irq number" is some random cookie, but it is a cookie that the *system* forces on the driver, and that is totally independent of how the irq is delivered or what kind of irq it is (device, system, PCI, ISA, whatever). The driver doesn't get to choose it, but the system and the driver have to agree on it some way (ie regardless of whether it's a PCI driver or a Super-Integrated-bus-of-year-2025, the driver will have to get it from some system resource, ie the pci_dev or whatever)
IOW, the irq number *does* have meaning, but it is very much by design something that is _purely_ a cookie. You cannot look into it - it's not a pointer to any data.
- "the name". There really is no point to passing this around, because it's purely for show, and purely so that the generic irq layer can tell the user something in /proc/irq etc. Passing it back to the driver would be entirely pointless, because it is designed purely to be a driver->system informational thing.
- the "device cookie". This is the thing that the system itself doesn't care about, and is _entirely_ under control of the driver, so the driver can pass its own interrupt controller some helpful instance pointers.
So of the three, "device cookie" is the one that we absolutely have to have. The irq number is not necessary, but it does actually have some meaning especially for legacy devices (eg ISA), and it is at least _sensible_ to pass around (ie it has no downsides, and it's not fundamentally broken). And the name would be just stupid.
EVERYTHING else would be architecture-specific. And that is exactly what we do not want. EVER.
Passing in some context that contains bus information is absolutely the *last* thing we want. We do not want to have irq handlers that know about the interrupt controller details.
Linus
| |