Messages in this thread | | | Date | Thu, 24 Apr 2008 11:40:22 -0400 | From | Jeff Garzik <> | Subject | Re: [git patch] free_irq() fixes |
| |
Linus Torvalds wrote: > 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.
Agreed.
However, it does not follow that an int is what _must_ be passed around. We already have design patterns like
cookie_pointer = ioremap(raw bus resource)
Not that I am the one pushing for that, just noting.
Overall this is all wild-assed speculation based on a thought exploration (#irq-remove) that a several kernel hackers seemed to like.
> - 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.
Agreed.
> EVERYTHING else would be architecture-specific. And that is exactly what > we do not want. EVER.
Not true -- you have metadata/OOB data like MSI messages, where you are passed a value from the PCI hardware in the PCI message, not just an "interrupt asserted" condition. Or s/value/values/ if you enable PCI MSI's multiple message support.
The PCI devices themselves are moving from sending a single bit of information ("irq!") to sending actual messages.
That is not arch-specific at all, but a new model for "interrupt" (i.e. event) notification being pushed upon us.
Jeff
| |