Hello Raveendra, I was checking examples of IRQ handlers in IIO drivers when I noticed that bcm_iproc_adc.c appears to use devm_request_threaded_irq() incorrectly. The third argument of devm_request_threaded_irq() is the primary handler. It is called in hardirq context and checks whether the interrupt is relevant to the device. If the primary handler returns IRQ_WAKE_THREAD, the secondary handler (a.k.a. handler thread) is scheduled to run in process context. It is typical for the secondary (but not the primary) handler to have the work "thread" in its name. It looks like bcm_iproc_adc.c uses the secondary handler as the primary one and the other way around. iproc_adc_interrupt_thread() is passed to devm_request_threaded_irq() as the primary handler, but it doesn't ever return IRQ_WAKE_THREAD. The use of "thread" in the name is another indicator that the function is not used properly. iproc_adc_interrupt_handler() is passed to devm_request_threaded_irq() as the secondary handler. But it actually does what the primary handler should do. It checks that the interrupt belongs to the device and returns IRQ_WAKE_THREAD. The fix should be to swap the third and the fourth arguments to devm_request_threaded_irq(). But I don't have the hardware to test it. -- Regards, Pavel Roskin -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
