We haven't even given a try to fixing it; I think the revert is still hasty.
I don't have a machine that can reproduce this failure, but I did confirm that my keyboard still works with this:
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 1dd8d5aebf678..b74d7d8cc8630 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -19,7 +19,7 @@
#include <linux/dmi.h>
#ifdef CONFIG_X86
-#define valid_IRQ(i) (((i) != 0) && ((i) != 2))
+#define valid_IRQ(i) ((i) > 2)
static inline bool acpi_iospace_resource_valid(struct resource *res)
{
/* On X86 IO space is limited to the [0 - 64K] IO port range */
Can we perhaps see if that works instead for some affected people?
That does not just skip the override stuff, it will make the kernel return irqresource_disabled(res, 1) for the kbd IRQ:
static inline void irqresource_disabled(struct resource *res, u32 irq)
{
res->start = irq;
res->end = irq;
res->flags |= IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
}
Now not much code seems to actually check the IORESOURCE_DISABLED | IORESOURCE_UNSET flags, so this might still work but it does not seem like the right thing to do.
Right; so it makes the resource get skipped when PNP is enumerated.
To me it seems that it should match the theme of 'don't reprogram the
polarity and triggering for the IRQ'. When the IRQ is set up by i8042
then it will try to go and get a resource and wouldn't find one. So
when the IRQ is set up it should match the values already programmed.
I do wonder if both IRQ 1 and IRQ 12 both would need to be skipped for
this to work (if people are affected by both i8042 devices).
