Messages in this thread | | | From | Linus Walleij <> | Date | Thu, 6 Aug 2020 15:32:41 +0200 | Subject | Re: [PATCH] gpio: siox: indicate exclusive support of threaded IRQs |
| |
On Thu, Aug 6, 2020 at 12:20 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> So the solution for this driver is either to make the dispatch handler > threaded or use the hard interrupt variant of dispatching the > demultiplexed GPIO interrupts.
The struct gpio_irq_chip .threaded bool that the patch sets just instructs the gpio core to issue irq_set_nested_thread(irq, 1) on the child IRQ.
This is a driver of type "struct siox_driver" handling the IRQ through the special .get_data callback supplied in the driver struct and it calls handle_nested_irq(irq) so with this fix it percolated up to the parent as intended.
So far so good. So I think the patch should be applied.
But what is behind this .get_data() callback for siox drivers?
The siox driver framework in drivers/siox dispatches calls to .get_data() from a polling thread which is just some ordinary kthread. It looks like this because the SIOX (I think) needs to do polled I/O. (drivers/siox/siox-core.c)
So this is a thread but it is not an irq thread from the irq core, however it is treated like such by the driver, and in a way what happens is events, just polled by a thread.
So when we call handle_nested_irq() ... we are not really calling that from an irq handler.
I am just very confused :D
But Uwe must have designed this thread to mimic IRQs specifically? (Uwe?)
I don't know if the IRQ core even sees a difference between which thread it gets interfaced with. I suppose it does? :/
Yours, Linus Walleij
| |