Parrallel to https://bugzilla.kernel.org/show_bug.cgi?id=216552 On the TongFang GMxRGxx this patch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.15.69&id=3bb12efc5e4d2b237230a4c6919b6fcf81d61190 breaks the build in keyboard support. With it reverted the keyboard is functional again. The ACPI is also using the IRQNoFlags macro in the _CRS namespace.
Created attachment 303191 [details] dmesg befre revert (built in keyboard unresponsive)
Created attachment 303192 [details] dmesg after revert (built in keboard functional)
Created attachment 303193 [details] acpidump -b
If it's only singular devices: Since a skip_override_table already exists, the easy solution would be to also add a force_override_table. Depending on how resposive GPD and TongFang are.
Can you talk to GPD and TongFang and ask them to switch 'IRQ' ASL keyword to 'Interrupt' and set interrupt polarity appropriately?
I have no conect to gpd, I just mentioned it because of the other bugreport. I can conntact TongFang and ask them for a BIOS update, however a lot of these barebones are already in the wild (it's sold since 3 month? 4 month?) and all would need the update, so a way to quirk it would still be very practical. If you agree I will put together a patch with a in source quirk list and/or module parameter to switch to the old behaviour (unless it has some negative side effects?).
It seems to me generally the patch is turning out shortsighted because some IBVs are doing something different. We could potentially keep adding to the list but it's going to get rather convoluted and not sustainable. IE: If it's using legacy syntax and this firmware disagrees with this other firmware; use an override, but not if AMD zen; but if it's AMD zen and in this other list then use the override anyway. So I think that we do want to revert it; but we need a better solution to go with it so we don't just trade off these machines not working for others not working. My idea is that we should push for i8042 to validate IRQ1 works and if it doesn't then try to change the polarity of the IRQ on the IOAPIC. There is something in drivers/input/serio/i8042.c that tests IRQ12 works (which is used for PS/2 mouse typically). I wonder if we can do something similar?
(In reply to Mario Limonciello (AMD) from comment #7) > It seems to me generally the patch is turning out shortsighted because some > IBVs are doing something different. > > We could potentially keep adding to the list but it's going to get rather > convoluted and not sustainable. I fully agree that we need a better fix for this. How to do a better fix should probably be discussed with Dmitry Torokhov <dmitry.torokhov@gmail.com>.
BTW has someone checked if the solution could be as simple as simply always overriding the irq-trigger to be of a certain type? The ps/2 / i8042 controller is such a legacy device that I really expect it to always have the same IRQ polarity everywhere ? (or at least on x86/ACPI platforms).
Got and updated bios from tongfang which is now wokring with the new kernel. In the old bios the PS2K _CRS method used the IRQ macro, in the new bios it is using the IRQNoFlags Macro. So it seems like they did the exact opposite than suggested in the gpd bug report, but it somehow works?
Created attachment 303248 [details] ACPI dump with patch from tongfang, working with current kernels
ok this bios seems to work with both, old and new, kernels
TongFang asked me if they should include the fix in all future bios releases. Just wanna double check here what the intended way is?
They'll know best what they want to have the polarity programmed. It's best that they use the Interrupt() macro instead of IRQ() or IRQNoFlags() because this will completely avoid this workaround codepath no matter what we do. In terms of the question of whether to include a solution for this in all BIOS releases - the answer is probably Yes*. *The intended way is that they test all their systems with modern Linux kernels and adjust the BIOS to ensure that they work!
Well, ... we are happy that they are at least at the point that they fix linux specific bugs when we report them, and not just deny the existence of anything but windows xD But i will let them know that it's fine to carry the change over.
Did the ideas on how to fix this for good move anywhere?
(In reply to wse from comment #16) > Did the ideas on how to fix this for good move anywhere? Never mind, found out that for the time being the qurik table approach was chosen: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7592b79ba4a91350b38469e05238308bcfe1019b I will just add this device to the list and send it upstream.