Hi

On 1/3/22 18:40, Hans de Goede wrote:
> So we do eventually get an IRQ request for a pin using the GPIO controller
> internal interrupt-line 0. But the IRQ triggers at least once before then and
> even though we haven't set a handler yet, calling generic_handle_irq for the
> GPIO-chips irqdomain, offset 0 IRQ does manage to silence the interrupt.
> 
> I've been tracing this through the kernel code and AFAICT we end up in:
> 
> arch/x86/kernel/irq.c: ack_bad_irq() in this case:
> 
> Which means that this message should show up in dmesg:
> 
>          if (printk_ratelimit())
>                  pr_err("unexpected IRQ trap at vector %02x\n", irq);
> 
> Can you confirm this? Also can you share the full dmesg output of this
> device (with both patches, with dyndbg option) ?
> 
Hmm.. don't see it. Attached dmesg_20220103 is with both yesterday's 
patches.

> Note what we are seeing here is basically a spurious IRQ. Except on a few
> known broken devices the cherryview pinctrl code relies on the BIOS having
> configured things so that there are no spurious IRQs. I've attached a
> quick hack which activates the workaround for known broken devices
> unconditionally. This replace my previous 2 patches. I expect this to
> fix things too.
> 
> If you can make some time to give this one a test too that would be
> great, then we have some options on how to fix this :)
> 
Hack patch booted too. Attached dmesg_20220104-hack is from this test.

Jarkko