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
