This will be handy for interrupts issued from I2C and SPI chips, too ... their handlers mostly need to run in task context, since they've got to block while their messages get to the head of the I/O queue and also while waiting for the response. Example: IRQ comes in, block until the IRQ status mask comes back from the chip. (Even when that serial bus was idle when the IRQ came in, the handler must block.)
It's not clear how useful it will be for chained handlers though. As in, an I2C chip may have a few dozen internal IRQ sources, each of which needs to be dispatched as an IRQ in its own right. Not only will the top level dispatcher need to be a thread (possibly shared by the handlers for those internal sources) ... but all the irq_chip methods to update IRQ masks and trigger modes for those internal IRQ sources will need to run in threads, too...
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds