On Mon, Mar 12, 2018 at 5:45 PM, Daniel Kurtz <djkurtz@xxxxxxxxxxxx> wrote: > In certain cases interrupt enablement will be delayed relative to when > the InterruptEnable bits are written. One example of this is when > a GPIO's "debounce" logice is first enabled. After enabling debounce, > there is a 900 us "warm up" period during which InterruptEnable[0] > (bit 11) will read as 0 despite being written 1. During this time > InterruptSts will not be updated, nor will interrupts be delivered, even > if the GPIO's interrupt configuration has been written to the register. > > To work around this delay, poll the InterruptEnable bits after setting > them to ensure interrupts have truly been enabled in hardware before > returning from the irq_enable handler. > > Signed-off-by: Daniel Kurtz <djkurtz@xxxxxxxxxxxx> Patch applied. I see the AMD people were not on CC so adding them here so they can say if there is any problem with the approach. Daniel: maybe you should consider listing yourself as comaintainer of this driver? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html