[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871rkkhy7v.fsf@nanos.tec.linutronix.de>
Date: Thu, 06 Aug 2020 12:20:52 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>,
Ahmad Fatoum <a.fatoum@...gutronix.de>,
Linus Walleij <linus.walleij@...aro.org>,
Bartosz Golaszewski <bgolaszewski@...libre.com>
Cc: Thorsten Scherer <t.scherer@...elmann.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] gpio: siox: indicate exclusive support of threaded IRQs
Uwe Kleine-König <u.kleine-koenig@...gutronix.de> writes:
> On Tue, Aug 04, 2020 at 11:16:03AM +0200, Ahmad Fatoum wrote:
>> Generic GPIO consumers like gpio-keys use request_any_context_irq()
>> to request a threaded handler if irq_settings_is_nested_thread() ==
>> true or a hardirq handler otherwise.
>>
>> Drivers using handle_nested_irq() must be sure that the nested
>> IRQs were requested with threaded handlers, because the IRQ
>> is handled by calling action->thread_fn().
>>
>> The gpio-siox driver dispatches IRQs via handle_nested_irq,
>> but has irq_settings_is_nested_thread() == false.
>>
>> Set gpio_irq_chip::threaded to remedy this.
>
> Sounds reasonable, but I have to keep this for others to judge if this
> is indeed how the irq stuff works.
handle_nested_irq() documentation clearly says: "Handle a nested irq
from a irq thread". As a consequence the caller of this function must
run in an interrupt thread. This is an optimization to spare tons of
interrupt threads and context switches.
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.
Thanks,
tglx
Powered by blists - more mailing lists