Comment 96 for bug 2034477

(In reply to Hans de Goede from comment #14)
> Hi p0lloc,
>
> I read in bug 217873 that you already have tried to add your model to the
> DMI quirks to make drivers/acpi/resource.c use the MADT override info on
> your AMD Zen based laptops resulting in:
>
> ACPI: IRQ 1 override to edge, high(!)
>
> Showing up in the log, which is what that DMI quirk should do. So it looks
> like you got the patch right but this unfortunately does not help.
>
> This suggests that your IdeaPad Slim 3 14AMN8 is a whole new category of kbd
> IRQ bug where neither the DSDT nor the MADT override info is correct (what
> fun).
>
> This really shows once more that to fix this once and for all we need to
> find a way to readback the actually IRQ settings setup by the BIOS at boot
> and use those (ignoring all the tables which tell us the info since those
> seem to be unreliable).
>
> But for now first lets confirm that this really is an IRQ type / polarity
> issue.
>
> By default 6.6-rc5 uses "edge low" as trigger type and with the DMI quirk
> which you tested it uses "edge high" as trigger type and neither works.
>
> We have seen several Intel based laptop models which need to NOT use the
> MADT override so that they stick with the DSDT setting of "level low" so
> lets give that a try.
>
> I'll attach a quick hack which ignores all the ACPI tables and just sets
> IRQ1 directly to "level low". Please build a kernel with this and see if
> this helps.
>
> If it does not help please try "level high" by changing:
>
> u8 pol = ACPI_ACTIVE_LOW;
>
> to:
>
> u8 pol = ACPI_ACTIVE_HIGH;
>
> Note a level IRQ with the wrong polarity (low vs high) will lead to an
> interrupt storm which might very well lead to a non booting system. So make
> sure you have an entry for another kernel in your grub menu as fallback.
>
> Also if the IRQ storm is not "bad" enough it may seem as if everything
> works, while at the same time the CPU is very busy.
>
> So if things seem to work please run:
>
> cat /proc/interrupts
>
> and check that the numbers for IRQ 1 are not going crazy (each keypress
> should add 2 to the IRQ count one for press + one for release).

Hello Hans, thank you for the swift response!
I tried applying your patch but unfortunately it doesn't seem to help.
Curiously I get the message "ACPI: IRQ 1 override to edge(!), high" and not "level(!), low" as you suggested.
Looking at the source code, it doesn't seem that the variables "t" or "p" are ever modified, so I assume it should always show "edge" and "high"?

I went ahead and tried all combinations of edge/level and high/low but sadly to no avail.
This is the output in dmesg:
LEVEL_SENSITIVE ACTIVE_LOW: edge(!), high
LEVEL_SENSITIVE ACTIVE_HIGH: edge(!), high(!)
EDGE_SENSITIVE ACTIVE_HIGH: edge, high(!)
EDGE_SENSITIVE ACTIVE_LOW: no override message