On Mon, Jan 21, 2019 at 11:52:50AM +0100, Bartosz Golaszewski wrote: > sob., 19 sty 2019 o 10:03 Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> > napisał(a): > > > > Hi Bartosz, > > > > On Fri, Jan 18, 2019 at 02:42:43PM +0100, Bartosz Golaszewski wrote: > > > + input_set_capability(onkey->input, EV_KEY, onkey->code); > > > + > > > + rv = devm_request_threaded_irq(dev, irq_f, NULL, > > > > Why threaded interrupt with only hard interrupt handler? If parent > > interrupt is threaded use "any_context_irq" here. > > > > Hi Dmitry, > > actually it's the other way around. Take a look at the function > prototype for devm_request_threaded_irq()[1]. > > The third parameter is the hard-irq handler (NULL in my patch), the > fourth is the thread function. Actually even if I did what you're > saying - it would never work as this is a nested irq for which the > hard-irq handler is never called. Sorry, my eyes must have crossed. Still, from the driver POV the interrupt does not have to be threaded, this is dictated by the constraints beyond the driver control. For these cases we have devm_request_any_context_irq() that takes essentially only "hard" IRQ handler, but internally either does request_irq() or request_threaded_irq(), depending on the context (whether the interrupt is nested or not). Using devm_request_any_context_irq() should not have any behavioral changes, but documents the logic better. Thanks. -- Dmitry
