On 8/7/2023 12:06, Hans de Goede wrote:
Hi,
On 8/7/23 13:39, Mario Limonciello wrote:
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.
Which AFAICT means that PNP enumerated i8042-s will not have any IRQ assigned at all and this will not work.
Regards,
Hans
Yeah; I did some experimentation with some other machines and confirmed
this doesn't work reliably on everything.
Your newly proposed direction sounds good to me though. If you can post
a new patch for that I'll test on the stuff I have.
