On Fri, Sep 03, 2010 at 10:46:55AM +0530, Trilok Soni wrote: > Hi Dmitry, > > On 9/3/2010 1:54 AM, Dmitry Torokhov wrote: > >> > > > > 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. > > > > Well, how I see the request_any_context_irq(...) call is that when the caller > doesn't know the protocol being setup from the irq core code Well, here lies the difference in our approaches ;) For me it is not that the driver does not know, but that it does not _care_. It, by itself, can work in both threaded and hard interrupt mode. I do believe that driver should request threaded interrupts only if they need threaded interrupts. > and how the line > he is controlling was being setup, so in that case request_any_context_irq(..) > to be the safest call. But in this case we know that it will be __always__ > threaded due the PMIC driven over slow bus. > > May be multiple APIs are now causing confusion :) > 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
