Hi Trilok, On Fri, Sep 03, 2010 at 01:23:55AM +0530, Trilok Soni wrote: > Hi Dmitry, > > On 9/2/2010 10:52 PM, Dmitry Torokhov wrote: > > > >>> > >>> I'll change it to use normal interrupts locally, no need to resubmit. > >> > >> Changing it to request_irq() will cause it to fail, because __setup_irq > >> will error out if this is a nested thread interrupt and no interrupt > >> thread is specified. request_any_context_irq() should work, if you > >> would like to get rid of explicitly asking for a threaded irq. > >> > > > > OK, request_any_context_irq() it is then. > > Though request_any_context_irq() would work here, but I would still > prefer to use the request_threaded_irq(..) because power-on key functionality > is in-built to this PMIC chip and it will always be threaded it seems. No new > thread will be created because they did the right thing in their PMIC core > irq code it seems. > > We could prefer the request_any_context_irq(...) when we are using the line > (say gpio) coming out of this PMIC and used by generic device driver where > the another h/w design could have memory mapped gpio for the same device driver. > > Better to keep this driver with request_threaded_irq(..) only. > I disagree. I believe that drivers should use request_threaded_irq() only if they _themselves_ require handling interrupts in process context. The fact that someone up the stack set up threaded IRQ and not hard IRQ should not matter. Ideally I'd love request_irq() to be what request_any_context_irq() currently is and then we'd have request_hard_irq() for driver that absolutely need hard IRQ context. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
