Hello Pavel, Yes, this is a bug. Tested suggested change and it works fine. Please send the patch, I will ack the same. Regards, Raveendra On Tue, May 9, 2017 at 3:03 AM, Pavel Roskin <plroskin@xxxxxxxxx> wrote: > 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
