https://bugzilla.kernel.org/show_bug.cgi?id=217873
--- Comment #14 from Rob Whalley (m...@robwhalley.co.uk) --- Well, I'm stumped. Using the latest version of the file from https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/acpi/resource.c that includes some simplification / consolidation, have tried patching drivers/acpi/resource.c to add the vendor and board name to either irq1_level_low_skip_override or irq1_edge_low_force_override... /* * DMI matches for boards where the DSDT specifies the kbd IRQ as * level active-low and using the override changes this to rising edge, * stopping the keyboard from working. */ static const struct dmi_system_id irq1_level_low_skip_override[] = { ... /* * DMI matches for AMD Zen boards where the DSDT specifies the kbd IRQ * as falling edge and this must be overridden to rising edge, * to have a working keyboard. */ static const struct dmi_system_id irq1_edge_low_force_override[] = { ... static const struct irq_override_cmp override_table[] = { { irq1_level_low_skip_override, 1, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, false }, { irq1_edge_low_force_override, 1, ACPI_EDGE_SENSITIVE, ACPI_ACTIVE_LOW, 1, true }, }; The six override values map to dmi_system_id, irq, triggering, polarity, shareable, override (see irq_override_cmp). This page was useful in broadly understanding the differences in high/low/edge/level triggering: https://wiki.osdev.org/MADT The information from the decompiled DSDT (PNP0303) attached previously looks like it might match irq1_edge_low_force_override... IRQ (Edge, ActiveLow, Shared, ) {1} This is the very simple patch added, pretty much a copy of the "PCSpecialist Elimina Pro 16 M" quirk from bug 217394: + { + /* + * Lenovo IdeaPad Slim 3 15AMN8 + * + * Matching on board-name. + */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_MATCH(DMI_BOARD_NAME, "LNVNB161216"), + }, + }, With the laptop identifiers added to irq1_edge_low_force_override, the dmesg output included: ACPI: IRQ 1 override to edge, high(!) So, at least it was possible to say the patch had an effect, albeit not one that resulted in a fix. Various combinations of the pci / acpi kernel parameters were tried without any luck, both in patched and unpatched states: https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt Confirmed p0lloc's combination of parameters do the same here. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. _______________________________________________ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
