Created attachment 293345 [details] The patch I currently use My laptop is HP Gaming Pavilion - 15-cx0095tx. This laptop has the same EC command and data address on ec & boot_ec, however, the GPE number is different. On boot, it uses 0x17 as GPE, but after that, the GPE is 0x14. Currently, there is a quirk fix for ASUS laptop in acpi_ec_add(), but I think it should not be there. (I think this is caused by: 69b957c26b32c3407d1b8cc0d2390b271728db8a) --- Detailed Information: - Kernel version: 5.9.2 - Distribution: Arch Linux - Command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=72ecfe23-1521-442e-a2aa-abcb1dff4180 rw resume=UUID=0872bf8b-b786-428a-9d9e-5aeb967e91eb log_buf_len=64M acpi.debug_layer=0x2fffffff acpi.debug_level=0x2 wmi.debug_event=1 "dyndbg=module acpi +p"
Created attachment 293347 [details] The decompiled ECDT
Created attachment 293349 [details] Part of the DSDT to provide the EC information
After apply the patch, my AC adapter events and WMI related hotkeys are back. Since the patch is a dirty fix, it is suppose to break other model computers.
Let's see what Rafael thinks about this.
please attach the dmidecode for this laptop.
Created attachment 297041 [details] The dmidecode of the Laptop
Created attachment 297065 [details] quirk patch to use ECDT GPE for this HP laptop Please apply this patch on top of latest upstream Linux kernel and check if it works as expected.
I applied the patch on 5.12.9. However, the patch doesn't work. Should I expect "Detected system needing ignore DSDT GPE setting." appears in dmesg?
(In reply to Shao Fu, Chen from comment #8) > I applied the patch on 5.12.9. However, the patch doesn't work. > > Should I expect "Detected system needing ignore DSDT GPE setting." appears > in dmesg? you should only after enabling the EC dynamic debug. I don't see why it fails. please attach the output of "dmidecode -s system-manufacturer" and "dmidecode -s system-product-name". Please make a double check that you're running with the customized kernel, say, you can add a printk in the ec driver probe function, and make sure your kernel can print the new message you added.
I found the "Detected system needing ignore DSDT GPE setting." message after I add back the `log_buf_len` parameter. However, the actual issue is not resolved. It still use the 0x17 as GPE (in ECDT) after boot. It should use 0x14 as GPE (in DSDT) after the boot process. In this case, ignoring DSDT GPE setting cannot be used.
without your patch, in acpi_ec_ecdt_probe() boot_ec->gpe is 0x17 boot_ec->handle is ACPI_ROOT_OBJECT first_ec is boot_ec kernel default behavior acpi_init() (subsys_initcall) -> acpi_bus_init() -> acpi_ec_ecdt_probe() : boot_ec->gpe = 0x17 : boot_ec->hndle = ACPI_ROOT_OBJECT -> acpi_ec_dsdt_probe() : nop -> acpi_ec_init() -> acpi_ec_add() -> ec_parse_device : alloc ec struct for EC0 (DSDT EC) : dsdt_ec->gpe = 0x14 : with my patch: dsdt_ec->GPE = 0x17 : dsdt_ec->handle = EC0 : boot_ec->handle = EC0 : dsdt_ec = boot_ec -> acpi_ec_ecdt_start() : nop with your patch: acpi_init() (subsys_initcall) -> acpi_bus_init() -> acpi_ec_ecdt_probe() : boot_ec->gpe = 0x17 : boot_ec->hndle = ACPI_ROOT_OBJECT -> acpi_ec_dsdt_probe() : nop -> acpi_ec_init() -> acpi_ec_add() -> ec_parse_device : alloc ec struct for EC0 (DSDT EC) : dsdt_ec->gpe = 0x14 : with my patch: dsdt_ec->GPE = 0x17 : dsdt_ec->handle = EC0 -> acpi_ec_ecdt_start() : boot_ec->handle = \_SB.PCI0.LPCB.H_EC : register a fake ECDT EC object So the difference is not just about GPE, it actually means we should have a separate device object for ECDT EC, even if the command/data register are duplicated, which suggests the DSDT EC may not be sufficient, and we rely on ECDT EC to work even after DSDT EC is probed. please attach the full acpidump output using "acpidump > acpidump.out". please attach the full dmesg output after boot, with ec dynamic debug enabled.
Created attachment 297255 [details] dmesg with "dyndbg=module acpi +p"
Created attachment 297257 [details] Full acpi dump
(In reply to Shao Fu, Chen from comment #12) > Created attachment 297255 [details] > dmesg with "dyndbg=module acpi +p" is this done with or without your patch? Please attach the dmesg output for both cases.
(In reply to Zhang Rui from comment #14) > (In reply to Shao Fu, Chen from comment #12) > > Created attachment 297255 [details] > > dmesg with "dyndbg=module acpi +p" > > is this done with or without your patch? > Please attach the dmesg output for both cases. This is done under the patch provided by you. I will attach another one after I recompile the kernel and reboot.
Created attachment 297261 [details] dmesg under my patch
and also the dmesg with default kernel, which does not contain our patches.
Created attachment 297279 [details] dmesg of Arch Linux official kernel
Created attachment 297281 [details] debug patch to avoid duplicate DSDT EC with ECDT EC if GPEs are different I see. So the root cause is that, DSDT EC and ECDT EC share the same port address but different GPEs. And it is the DSDT EC gpe that really works. Please confirm if the debug patch, on top of vanilla Linux, works or not, if yes, I will raise this and try to push an upstream solution.
Maybe we need a new quirk list for this issue.
Created attachment 297283 [details] debug patch: quirk list for trusting DSDT GPE Please also confirm if this patch fixes the problem or not, on top of vanilla kernel.
Created attachment 297297 [details] dmesg after applying #297281 I have tried the "debug patch to avoid duplicate DSDT EC with ECDT EC if GPEs are different". The patch can correctly fix this bug, the ACPI hotkeys and power notification are working. I will try the other patch ASAP.
Created attachment 297425 [details] dmesg after applying #297283 This quirk patch is also works as expected.
Created attachment 297427 [details] Patch target for upstream Great. Thanks for the test. I changed the code and changlog to come up a version that is targeted for upstream Linux kernel. In theory this does not contain any functional change. can you please try this on top of the vanilla kernel and see if it fixes the problem for you? If yes, I will submit this patch for usptream.
I applied the patch on 5.12.10 and it works very well now. Thanks for your help on this issue.
Patch has been queued for next merge window. Bug closed. Thanks for reporting, Shaofu!