On Sat, May 7, 2016 at 1:15 PM, Jonathan Cameron <jic23@xxxxxxxxxxxxxxxxxxxxx> wrote: > Shortens the race but doesn't prevent it that I can see.. I thought about it tonight, and I need to add one more thing to make the solution perfect: avoid registering the interrupt with IRQF_ONESHOT. That way the top half will always be executed if a new IRQ comes in. The top half will be really fast and always ready to recieve new IRQs. As the IRQ is always edge-triggered on these devices, we need not worry about the IRQ handler locking up: IRQF_ONESHOT is essentially for level IRQs that just keep the line low until you served the IRQ. Then we need the top half to tell the bottom half that a new IRQ has arrived. Right now I am thinking about letting the top half increase an atomic counter any time a new IRQ comes in and that way we can check from the thread if a new IRQ arrived before exiting. We still need to re-check the status from I2C reads again: as the interrupt line may be shared, some other device could have fired the IRQ, but as long as the *last* thing we check before exiting the thread is the irq counter, we should be pretty safe. It would have the same precision as polling the GPIO line anyways. Let me cook a patch like this and you can see what I mean! Yours, Linus Walleij -- 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
