Bug 214749

I don't think that this is kernel fault. I noticed the same issue with Linux Mint with kernel "5.4.0-84-generic".

The log errors are different though, but the behaviour is the same: I wake up the laptop after suspend and touchpad freezes.

I added a new attachment (linuxmint_touchpad_freeze)

Now I'm checking if under Windows I have the same issue, to know if this is a hardware bug.

Created attachment 299279 [details]
linuxmint_touchpad_freeze

As you can see, the errors are different, journalctl says: "kernel: i2c_hid i2c-ELAN2204:00: i2c_hid_get_input: incomplete report (14/65535)" in loop.

Ok, I confirm that this is a GNU Linux bug. I tried Windows and it does not have this issue, so it's not an hardware problem. Using the touchpad on Linux is frustrating because it can randomly freeze after you wake up your laptop from suspend. And you MUST reboot to unfreeze it.

In the above posts I said that doing: "sudo modprobe -r hid_multitouch i2c_hid_acpi && sudo modprobe i2c_hid_acpi hid_multitouch" does not fix the issue. Actually if I do: "sudo modprobe -r hid_multitouch i2c_hid_acpi i2c_hid && sudo modprobe i2c_hid_acpi i2c_hid hid_multitouch" so I just added i2c_hid, IT WORKS, and I can avoid to reboot. It's a good news.

hid_multitouch is not needed to be unloaded/reloaded though. Only i2c_hid_acpi and i2c_hid are essentials.

I wrote this here: https://github.com/All3xJ/linux-on-huawei-matebook-d-14-amd#Touchpad (or gitlab). This FIXES the issue for me. You have to put sleep and resume hooks... the bug never happened to me since I did this.

I'm experiencing this on both on Ubuntu (20.04), kernel 5.11.0-40-generic, and Void.

I've yet to find a modprobe command that fixes it for me.

Created attachment 299671 [details]
journalcrl ubuntu 20.04 kernel 5.11.0-40-generic

I did not use my laptop on the morning, but might have activated it when I moved and unplugged a wireless mouse.

I have the same behavior with a Dell Vostro 5515
input: DELL0A7A:00 27C6:0D42 Mouse as /devices/platform/AMDI0010:03/i2c-0/i2c-DELL0A7A:00/0018:27C6:0D42.0006/input/input33
and 
[10847.076492] input: DELL0A7A:00 27C6:0D42 Touchpad as /devices/platform/AMDI0010:03/i2c-0/i2c-DELL0A7A:00/0018:27C6:0D42.0006/input/input34
The touchpad didn't respond after wake up from hibernation.
rmmod and modprobe i2c_hid_acpi did the trick without reboot

the kernel is #1 SMP Debian 5.15.5-2 (2021-12-18)

I have a similar problem with my touchpad.

It probes as "input: ASUE1201:00 04F3:3125 Touchpad as /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-11/i2c-ASUE1201:00/0018:04F3:3125.000C/input/input109"

It works fine until I suspend to S3, then when I resume, either :
- the touchpad is locked but sometimes moves randomly when I touch it (with hid_multitouch loaded)
- the pointer never stops and goes to one edge of the screen (without hid_multitouch).

I have the same IRQ error:
"i2c_hid_acpi i2c-ASUE1201:00: i2c_hid_get_input: IRQ triggered but there's no data"

I tried reloading the modules i2c_hid and i2c_hid_acpi, I does not help.
I also tired playing qith the quirks defined in drivers/hid/i2c-hid/i2c-hid-core.c .
In particular, { 0x1201, HID_ANY_ID, I2C_HID_QUIRK_RESET_ON_RESUME } does not help.
 
# additional info:

all others hid-related modules are blacklisted

$ uname -a
Linux duna 5.15.12-arch1-1 #1 SMP PREEMPT Wed, 29 Dec 2021 12:04:56 +0000 x86_64 GNU/Linux

After further investigation:

- my vendor/product id are actually 0x04F3, 0x3125

- enabling debug traces shows that the touchpad streams events constantly. When I'm not interacting with the touchpad, the last input is repeated forever.

It looks like the interrupt is always asserted (its a level-triggered interrupt if I understand correctly)

Any progress with ASUE1201 touchpad? Did you manage to get it working properly? 
I tried playing around with i2c_hid quirks too, but it seems like it doesn't do anything.

I did an upgrade to kernel 5.18.0-arch1-1 and I noticed this bug again. And it's not fixable with what I did here: https://bugzilla.kernel.org/show_bug.cgi?id=214749#c7

I notice the bug everytime I close the lid and reopen it. To "fix" I have to close the lid again to make laptop suspend and open it again to resume it. If it isn't fixed, I have to do it again etc and it should work again

I booted with an older kernel (linux-lts 5.15.45-1) and the bug is not there.

Inspecting the journalctl logs, it seems that when I open the lid for first time after suspend, it just doesn't DETECTS the touchpad. After closing and reopening the lid again, the logs show: 

Jun 09 06:22:20 Archy kernel: input: ELAN2204:00 04F3:3109 Mouse as /devices/platform/AMDI0010:01/i2c-1/i2c-ELAN2204:00/0018:04F3:3109.0003/input/input20
Jun 09 06:22:20 Archy kernel: input: ELAN2204:00 04F3:3109 Touchpad as /devices/platform/AMDI0010:01/i2c-1/i2c-ELAN2204:00/0018:04F3:3109.0003/input/input22
Jun 09 06:22:20 Archy kernel: hid-multitouch 0018:04F3:3109.0003: input,hidraw0: I2C HID v1.00 Mouse [ELAN2204:00 04F3:3109] on i2c-ELAN2204:00


I am uploading the txt journalctl log file. In this file there are the two lid opening, the first without recognize of touchpad, and the second open the touchpad is recognized.

Created attachment 301132 [details]
first open lid touchpad not recognized, the second one it's recognized

Maybe I did not put it well. When I say: "After closing and reopening the lid again" I mean that I wait that the PC suspends and the reopen the lid again.

The bug happens also if I don't touch the lid and just do "systemctl suspend", then press any key to wake PC, now the touchpad can't be moved, now I enter password, write again "systemctl suspend", press enter, and then wake PC again and voila the touchpad works again.

For what it's worth Allexj's workaround does not work with a ASUS BR1100 (BR11100CKA) using the latest BIOS 313 from May 5, 2022. This laptop has a ASUE1201:00 04F3:3125 Touchpad like some others also reported here. Kernel is 5.15.0-37-generic #39-Ubuntu SMP Wed Jun 1 19:16:45 UTC 2022. Kubuntu 22.04 LTS.

After "systemctl suspend" and pushing power button to wake up there's:

i2c_hid_acpi i2c-ASUE1201:00: i2c_hid_get_input: IRQ triggered but there's no data

and then a IRQ storm is apparent when watching the output of "watch -n 1 cat /proc/interrupts", which shows approx. 1000 touchpad interrupts per second and the laptop gets noticeably warm. So this is why the touchpad is sluggish or unresponsive: the interrupt stays asserted, but without data. When you put your finger on it to move the cursor, movement is drowning in a mass of bogus interrupts.

Unloading i2c_hid_acpi will at least stop the IRQ storm. But you lose the touchpad. Reloading the module restarts the IRQ storm. Using sysfs to remove Designware I2C controller from the PCI bus and rescanning the PCI bus does not help.

The problem is likely that touchpad comes to a f*cked up state on resume.

Doing "systemctl hibernate" and wake back up fixes it. On a hardware level that's the same as rebooting though. Not a solution.

I think all the touchpad would need is a host initiated reset to unf*ck it.

I2C_HID_QUIRK_RESET_ON_RESUME should do it? It can be added to the quirks list for the ELAN touchpads in i2c-hid-core.c (look for USB_VENDOR_ID_ELAN; I can confirm these quirks do get selected and applied even for this "ASUE1202" ASUS version of the ELAN touchpad).

But maybe the reset logic in i2c_hid_core_resume needs to be different:

First call i2c_hid_set_power with I2C_HID_PWR_ON and then call i2c_hid_hwreset afterwards.

Compiling a Linux kernel on this passive-cooled "Pentium Silver" hardware take about 25 years so I can't test it. :-(

Who has a faster CPU and build environment to try it?

So I spent the entire day experimenting and hacking the driver to call to i2c_hid_execute_reset in strategic places to reset the touchpad, but this changes absolutely nothing.

There must either be something very vendor-specific that needs to be done, or something needs to be changed at a lower level, because the culprit is not in the I2C HID driver.

Note that I don't know shit about Linux driver development or the I2C HID protocol, so I'll remove myself from this conversation and go back to Win10. :)

(In reply to Allexj)

Does your Laptop support Windows 10 "connected standby" aka. Suspend-to-Idle?

Try "echo freeze > /sys/power/state" to find out. Kernel documentation states it should always work, but Linux is Linux... :-)

Your laptop should sleep but not deep. Turn on should be nearly instant. Just userspace gets stopped, but hardware keeps power.

Wake your laptop and the touchpad should still work.

If you are satisfied with such a crap workaround, you can make it permanent by booting Linux with mem_sleep_default=s2idle

Why it's can be helping? System doesn't really sleep and touchpad never lose power. Never lose power means it can never go into the fucked up state. You sacrifice the battery life of your laptop for working touchpad.

this workaround works for me.
I also got a BR11100CKA laptop with the ASUE1201:00 04F3:3125 Touchpad and BIOS version 313.

Kiriko Takemura tranks for the answers! Unfortunately "echo freeze > /sys/power/state" apparently seems to shut the display down, but laptop is unresponsive, so if I type a key to wake it up, the screen remains black :/

I have this issue on a Desktop; Ryzen 9 3900X
If I resume from suspended state gpu is freezing, black screen only mouse showing. Recognizes no keyboard input. The lockscreen is showing after waiting a few minutes. But can’t login, 5.18.12 doesn’t have this bug. Discovered on 5.18.14 and 5.18.15.

Also seeing this problem when resuming from S3 sleep with an ELAN0406:00 04F3:30A6 Touchpad on a Razer laptop, Blade 15 Advanced Model (Mid 2021) - RZ09-0409/CH570.
BIOS 2.01 and 2.02 (latest atm) both affected.

As Kiriko Takemura suggested, I can confirm sleeping to s2idle avoids the problem- but of course fans are still running and power draw is higher.

Like Kiriko I've spent a while fiddling with different approaches to resuming the device in i2c-hid-core.c, but no luck so far.

This doesn't happen in Windows, so I'm reasonably confident it should be possible to resume the device correctly in Linux but I don't yet know what we're missing.

There is a very similar problem problem reported in kernel bug #214775, for an ELAN touchpad on a Thinkpad X1 Carbon Gen9 generating an IRQ storm after resume. Interestingly on that bug Lenovo have solved it with a BIOS update since 1.52.
See https://download.lenovo.com/pccbbs/mobiles/n32uj16w.txt - "Fixed an issue where touch panel might not work on Linux after resume, if "Linux S3" is set on "Sleep State" in BIOS Setup."

I'm still hoping we can work around this in the i2c-hid driver, but I'd love to know what Lenovo changed.

Perhaps we are looking in the wrong place by examining the i2c-hid driver, maybe this is a pinctrl problem similar to https://bugzilla.kernel.org/show_bug.cgi?id=203995

I've had success in avoiding the touchpad IRQ storm after S3 suspend by adjusting pinctrl-intel.c intel_pinctrl_should_save to always returns true (every pin was returning false on a Razer Blade 15 2021).

This isn't a general solution, but it points at the problem being the GPIO state after resume.

I'm also affected with a BR1100CKA (aka BR1100C), touchpad 04F3:3125 and BIOS 314.


Working with 5.19.12, both jmharris' suggestion and Mika Westerberg's patch in the most-recently-linked thread produce a blank, flashing-black-and-white screen on resume. It seems both unrecoverable and - with my ability - undiagnosable.


For the alternate power state suggestion, I noticed several times that problem persisted after the laptop was left for a certain amount of time, as if it had reached S3 somehow anyway. It may have been just my power settings, though.


Currently compiling Kiriko's quirk flag suggestion, but without the logic change. (i2c_hid_hwreset seems to already call i2c_hid_set_power that way?)

That build also flashed the screen. Also, plugging HDMI in while that was happening caused a panic.

Sorry - my previous tests were from a pristine kernel. Those results are likely unrelated.

Working from /usr/src on Debian testing (kernel 5.19.11), Mika Westerberg's patch seems to clear up the mouse issues from S3. I'm not sure how to interpret /proc/interrupts, etc., so I can't say more.

I'd be happy to test on this machine, but I'll probably need guidance.

Created attachment 302966 [details]
Save all intel pins that are in GPIO mode

This is a version of Mika Westerberg's patch from https://bugzilla.kernel.org/show_bug.cgi?id=203995 tested on Linux 5.19.14 which fixes the touchpad from resume for me on a Razer Blade 15, by avoiding the IRQ storm after resume.

I don't think this is suitable for upstream yet though- this problem was meant to have been solved by the 'intel_pin_to_gpio' lookup passed to gpiochip_line_is_irq, which was the preferred solution in https://github.com/endlessm/linux/pull/494

I can confirm that https://bugzilla.kernel.org/attachment.cgi?id=302966&action=diff fixes my touchpad resume-from-suspend problem on my Asus BR1100CKA.

Debian bullseye with a the patch applied to a 5.19.11 Debian kernel.

(In reply to Dale Smith from comment #34)
> I can confirm that
> https://bugzilla.kernel.org/attachment.cgi?id=302966&action=diff fixes my
> touchpad resume-from-suspend problem on my Asus BR1100CKA.



However, I also have a problem of it not noticing the USB-C charger after coming out of suspend.  Not if this worked before the applied patch.

(In reply to jacco from comment #24)
> this workaround works for me.
> I also got a BR11100CKA laptop with the ASUE1201:00 04F3:3125 Touchpad and
> BIOS version 313.

I too have a BR11100CKA and suggested change does keep the touchpad working afer a suspend.

Created attachment 303229 [details]
Pin state pre and post suspend on broken and fixed kernels

I've been in touch with Mika Westerburg who asked for the contents of /sys/kernel/debug/pinctrl/INT34C6\:00/pins and the pin numbers used.

See attachment for full pin state dumps.


On an affected kernel the pins change after suspend is:

< pin 37 (CLKOUT_48) 44:INT34C6:00 GPIO 0x80180102 0x0000003d 0x00000000
> pin 37 (CLKOUT_48) 44:INT34C6:00 GPIO 0x80980102 0x0000003d 0x00000000

< pin 50 (SRCCLKREQB_0) 69:INT34C6:00 mode 1 0x84000702 0x0000004a 0x00000000 [ACPI]
> pin 50 (SRCCLKREQB_0) 69:INT34C6:00 mode 1 0x84000700 0x0000004a 0x00000000
> [ACPI]

< pin 87 (I2S2_SCLK) 136:INT34C6:00 GPIO 0x84000201 0x00000065 0x00000000
> pin 87 (I2S2_SCLK) 136:INT34C6:00 GPIO 0x84000200 0x00000065 0x00000000

< pin 122 (I2C0_SCL) 177:INT34C6:00 mode 1 0x84000702 0x00000030 0x00000000 [ACPI]
> pin 122 (I2C0_SCL) 177:INT34C6:00 mode 1 0x84000700 0x00000030 0x00000000
> [ACPI]

< pin 221 (SRCCLKREQB_9) 355:INT34C6:00 mode 1 0x84000702 0x00000027 0x00000000 [ACPI]
> pin 221 (SRCCLKREQB_9) 355:INT34C6:00 mode 1 0x84000700 0x00000027 0x00000000
> [ACPI]


On the patched fixed kernel the pins change after suspend is:

< pin 50 (SRCCLKREQB_0) 69:INT34C6:00 mode 1 0x84000702 0x0000004a 0x00000000 [ACPI]
> pin 50 (SRCCLKREQB_0) 69:INT34C6:00 mode 1 0x84000700 0x0000004a 0x00000000
> [ACPI]

< pin 53 (SRCCLKREQB_3) 72:INT34C6:00 mode 1 0x84000700 0x0000004d 0x00000000 [ACPI]
> pin 53 (SRCCLKREQB_3) 72:INT34C6:00 mode 1 0x84000702 0x0000004d 0x00000000
> [ACPI]

< pin 221 (SRCCLKREQB_9) 355:INT34C6:00 mode 1 0x84000702 0x00000027 0x00000000 [ACPI]
> pin 221 (SRCCLKREQB_9) 355:INT34C6:00 mode 1 0x84000700 0x00000027 0x00000000
> [ACPI]


Pins 37 and 87 are involved, on the patched kernel these are restored by pinctrl-intel.c intel_restore_padcfg:

tigerlake-pinctrl INT34C6:00: restored pin 37 padcfg0 0x80180102
tigerlake-pinctrl INT34C6:00: restored pin 87 padcfg0 0x84000201

Thank you for sharing that, very useful.

Now, can somebody modify Mika's patch and check pin-by-pin to find the one that is messed up? I think it's all about pin #37 (CLKOUT_48), but I want to have a confirmation.

(In reply to Andy Shevchenko from comment #38)
> I think it's all about pin #37 (CLKOUT_48), but I want to have a
> confirmation.

Can confirm this seems to be the case, I adjusted intel_pinctrl_should_save to not have the intel_pinctrl_is_gpio patch and instead return true for pin 37 specifically. This also solves the IRQ storm from touchpad upon resume.

On 11/20/22, bugzilla-daemon@kernel.org <bugzilla-daemon@kernel.org> wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=214749
>
> --- Comment #39 from jmharris@gmail.com ---
> (In reply to Andy Shevchenko from comment #38)
>> I think it's all about pin #37 (CLKOUT_48), but I want to have a
>> confirmation.
>
> Can confirm this seems to be the case, I adjusted intel_pinctrl_should_save
> to
> not have the intel_pinctrl_is_gpio patch and instead return true for pin 37
> specifically. This also solves the IRQ storm from touchpad upon resume.

I'm curious how this affects the "not seeing charger on resume" problem.

-Dale

(In reply to Dietmar Cz from comment #10)
> I have the same behavior with a Dell Vostro 5515
> input: DELL0A7A:00 27C6:0D42 Mouse as
> /devices/platform/AMDI0010:03/i2c-0/i2c-DELL0A7A:00/0018:27C6:0D42.0006/
> input/input33
> and 
> [10847.076492] input: DELL0A7A:00 27C6:0D42 Touchpad as
> /devices/platform/AMDI0010:03/i2c-0/i2c-DELL0A7A:00/0018:27C6:0D42.0006/
> input/input34
> The touchpad didn't respond after wake up from hibernation.
> rmmod and modprobe i2c_hid_acpi did the trick without reboot

You have:
- AMD based laptop
- Goodix touchpad

Please, move it to the separate bug, because this looks to me as per
- Intel based laptop
- Elan touchpad

Created attachment 303250 [details]
Patch to test

Please, test the attached patch and tell me if it helps with Elan touchpad on Intel hardware.

(In reply to Andy Shevchenko from comment #42)
> Please, test the attached patch and tell me if it helps with Elan touchpad
> on Intel hardware.

Thanks for preparing this patch Andy, unfortunately it does not fix the touchpad problem. I did remove the gpio save patch, and added some debug to confirm the hid quirk was being applied.

Here is a diff of /sys/kernel/debug/pinctrl/INT34C6\:00/pin before and after suspend with the patch applied to Asus BR1100CKA, which is jasperlake:

-pin 186 (UART1_CTSB) 271:INT34C8:00 GPIO 0x40100100 0x00000069 0x00000000 [LOCKED tx]
+pin 186 (UART1_CTSB) 271:INT34C8:00 GPIO 0x40100102 0x00000069 0x00000000 [LOCKED tx]

(In reply to Dale Smith from comment #35)
> (In reply to Dale Smith from comment #34)
> > I can confirm that
> > https://bugzilla.kernel.org/attachment.cgi?id=302966&action=diff fixes my
> > touchpad resume-from-suspend problem on my Asus BR1100CKA.
> 
> 
> 
> However, I also have a problem of it not noticing the USB-C charger after
> coming out of suspend.  Not if this worked before the applied patch.

????

And today it seems to be working perfectly!
Sees the USB-C charger insert/removal both before and after suspend.
Shows running on AC or Battery.

(In reply to jmharris from comment #43)
> (In reply to Andy Shevchenko from comment #42)
> > Please, test the attached patch and tell me if it helps with Elan touchpad
> > on Intel hardware.
> 
> Thanks for preparing this patch Andy, unfortunately it does not fix the
> touchpad problem. I did remove the gpio save patch, and added some debug to
> confirm the hid quirk was being applied.

I see. Can you attach the output (on non-working case) before sleep and when problem occurs the output of the following commands?

- cat /proc/interrupts
- dmesg


Please, boot kernel with 'ignore_loglevel i2c_hid.debug=1'.

Meanwhile I want to prepare another test patch. Btw, can we do more debugging stuff via email? Because here it might be too noisy until we don't get some results.

(In reply to Dale Smith from comment #44)
> Here is a diff of /sys/kernel/debug/pinctrl/INT34C6\:00/pin before and after
> suspend with the patch applied to Asus BR1100CKA, which is jasperlake:
> 
> -pin 186 (UART1_CTSB) 271:INT34C8:00 GPIO 0x40100100 0x00000069 0x00000000
> [LOCKED tx]
> +pin 186 (UART1_CTSB) 271:INT34C8:00 GPIO 0x40100102 0x00000069 0x00000000
> [LOCKED tx]

I'm not sure which patch you are talking about: Mika's or mine?
If Mika's, then what we want is to see the post resume (when problem is happening / about to happen) in the non-working and working cases (it's enough to share the diff between those two).

(In reply to Andy Shevchenko from comment #47)
> (In reply to Dale Smith from comment #44)
> > Here is a diff of /sys/kernel/debug/pinctrl/INT34C6\:00/pin before and
> after
> > suspend with the patch applied to Asus BR1100CKA, which is jasperlake:
> > 
> > -pin 186 (UART1_CTSB) 271:INT34C8:00 GPIO 0x40100100 0x00000069 0x00000000
> > [LOCKED tx]
> > +pin 186 (UART1_CTSB) 271:INT34C8:00 GPIO 0x40100102 0x00000069 0x00000000
> > [LOCKED tx]
> 
> I'm not sure which patch you are talking about: Mika's or mine?
> If Mika's, then what we want is to see the post resume (when problem is
> happening / about to happen) in the non-working and working cases (it's
> enough to share the diff between those two).

This one: https://bugzilla.kernel.org/attachment.cgi?id=302966&action=diff

Doh!  Yeah, makes sense the diff between working and non-working is what's needed.
Not sure what I was thinking there...

Created attachment 303253 [details]
BR1100CKA notpatch/patch after suspend

Here is a diff of /sys/kernel/debug/pinctrl/INT34C6\:00/pin
nopatch -> patched after resume from suspend

(In reply to Dale Smith from comment #49)
> Created attachment 303253 [details]
> BR1100CKA notpatch/patch after suspend
> 
> Here is a diff of /sys/kernel/debug/pinctrl/INT34C6\:00/pin
> nopatch -> patched after resume from suspend

Thanks. It confirms that your case has the very same issue from technical perspective. If fixed for Tiger Lake, it will be fixed for you as well.

Created attachment 303279 [details]
Save and restore pins in "deirect IRQ" mode

Dale, John, and others, please give it a try.

Unfortunately, I still get the interrupt storm on the touchpad with
https://bugzilla.kernel.org/attachment.cgi?id=303279&action=diff

-Dale

Oh wait.   I think I patched that with --dry-run

Yeah.  Sorry about that.

(In reply to Dale Smith from comment #52)
> Unfortunately, I still get the interrupt storm on the touchpad with
> https://bugzilla.kernel.org/attachment.cgi?id=303279&action=diff
> 
> -Dale

Can you add the following after the value assignment in the intel_pinctrl_should_save():

  value = ...
  if (pin == 186) dev_info(pctrl->dev, "DW0: %x\n", value);

?

(In reply to Dale Smith from comment #53)
> Oh wait.   I think I patched that with --dry-run
> 
> Yeah.  Sorry about that.

Ah, okay, but I left the comment #54 anyway just in case if we need to debug further.

With the patch (properly) applied, the touchpad work perfectly after resume.
No interrupt storm.

Great job!  Thanks for all the effort.

-Dale

(In reply to Dale Smith from comment #56)
> With the patch (properly) applied, the touchpad work perfectly after resume.
> No interrupt storm.
> 
> Great job!  Thanks for all the effort.

Thank you for testing!

I'll wait for John's answer and if goes as expected, I'll submit it to upstream.

(In reply to Andy Shevchenko from comment #51)
> Created attachment 303279 [details]
> Save and restore pins in "deirect IRQ" mode
> 
> Dale, John, and others, please give it a try.

Solves the problem on the Razer Blade 15 too, good job and thanks!

(In reply to jmharris from comment #58)
> (In reply to Andy Shevchenko from comment #51)
> > Created attachment 303279 [details]
> > Save and restore pins in "deirect IRQ" mode
> > 
> > Dale, John, and others, please give it a try.
> 
> Solves the problem on the Razer Blade 15 too, good job and thanks!


Thank you for testing!

Formal submission is available here: https://lore.kernel.org/linux-gpio/20221124222926.72326-1-andriy.shevchenko@linux.intel.com/.