is there any more to having a single interrupt drive multiple handlers than IRQF_SHARED?
colleague just asked how he can use a single interrupt line to trigger more than one interrupt handler, and i just said, "well, IRQF_SHARED." i'm not sure if there's any more to this problem, but am i off-base in suggesting that that is pretty much what IRQF_SHARED is designed for? now, i do realize that it can be used along with a unique dev_id values to isolate a *particular* handler amongst a group of handlers, but if one simply wants to trigger *all* handlers registered for that interrupt, is there anything about that that's tricky? it seems pretty straightforward, but i'm going back to review my interrupt handlers this evening. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
On Thu, 26 Oct 2017 16:32:42 -0400, "Robert P. J. Day" said:
now, i do realize that it can be used along with a unique dev_id values to isolate a *particular* handler amongst a group of handlers, but if one simply wants to trigger *all* handlers registered for that interrupt, is there anything about that that's tricky?
You mean, other than the fact that multiple handlers for the same device damned well be coded to know that, and be aware of each other? Locking, etc. and all the other Bad Juju that can happen when multiple drivers are all acting on one device. What problem is your colleague trying to solve by doing this?
On Thu, 26 Oct 2017, valdis.kletnieks@vt.edu wrote:
On Thu, 26 Oct 2017 16:32:42 -0400, "Robert P. J. Day" said:
now, i do realize that it can be used along with a unique dev_id values to isolate a *particular* handler amongst a group of handlers, but if one simply wants to trigger *all* handlers registered for that interrupt, is there anything about that that's tricky?
You mean, other than the fact that multiple handlers for the same device damned well be coded to know that, and be aware of each other? Locking, etc. and all the other Bad Juju that can happen when multiple drivers are all acting on one device.
What problem is your colleague trying to solve by doing this?
i wish i had more info, but i don't ... all i'm after is that this is supportable via IRQF_SHARED and, when we chat again tomorrow, i might be able to figure out whether this is appropriate. having the handlers play nicely together will be phase two. rday p.s. is there an example of this usage somewhere in the kernel i can point at? i vaguely recall that PCI does something like this, so i'm off to take a look. -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
On Thu, Oct 26, 2017 at 2:17 PM, <valdis.kletnieks@vt.edu> wrote:
On Thu, 26 Oct 2017 16:32:42 -0400, "Robert P. J. Day" said:
now, i do realize that it can be used along with a unique dev_id values to isolate a *particular* handler amongst a group of handlers, but if one simply wants to trigger *all* handlers registered for that interrupt, is there anything about that that's tricky?
You mean, other than the fact that multiple handlers for the same device damned well be coded to know that, and be aware of each other?
They don't have to be aware of each other, only about the fact that their IRQ may be shared. And they have to be aware of that because they've registered their ISR with IRQF_SHARED flag.
Locking, etc. and all the other Bad Juju that can happen when multiple drivers are all acting on one device.
Not on one device, each handler will check registers of its own device, to see if it triggered the IRQ. -- Thanks. -- Max
participants (3)
-
Max Filippov -
Robert P. J. Day -
valdis.kletnieks＠vt.edu