On Mon, May 25, 2020 at 5:17 PM Kent Gibson <warthog618@xxxxxxxxx> wrote: > > I suppose gpiolib would have to steal or intercept the interrupt > > by using e.g. IRQF_SHARED and then just return IRQ_HANDLED > > on the first IRQ so the underlying irq handler does not get called. > > And how would gpiolib ensure that it was first in the chain? I don't know. > Totally agree with the concept - just trying to work out how to > implement it seemlessly given the existing API and usage, and given my > limited knowledge of the kernel internals. The irqchip maintainers certainly know the answer for the question of shared interrupts at least. > > Failure is an option! Sorry if I push too complex ideas. > > I'm not as concerned about complexity as I am about fragility. > > I don't see any problem adding debounce for gpiolib-cdev. > Adding a more complete solution to gpiolib itself is certainly > non-trivial, if it is possible at all. I agree. It's just that I perceive it as more elegant if we can do that. > The path I'll probably be taking is adding a debouncer to gpiolib-cdev, > so at least we have a solution for userspace, then take a longer look at > the more general solution. That's fine! Thanks for looking into this. Linus Walleij