[Bug 221383] New: ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[Bug 221383] New: ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

            Bug ID: 221383
           Summary: ideapad_laptop: Fn hotkeys stop emitting after s2idle
                    resume on IdeaPad Slim 3   14ARP10 (Ryzen 7735HS)
           Product: Drivers
           Version: 2.5
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Platform_x86
          Assignee: drivers_platform_x86@kernel-bugs.osdl.org
          Reporter: sindrehenriksen93@gmail.com
        Regression: No

Created attachment 309895
  --> https://bugzilla.kernel.org/attachment.cgi?id=309895&action=edit
dmesg after cold boot (working state)

Kernel version: 6.17.0-19-generic (Ubuntu 24.04.4 LTS HWE; upstream 6.17.13)

Hardware:
  Vendor:  LENOVO
  Product: IdeaPad Slim 3 14ARP10 (MTM 83K6 / board LNVNB161216)
  CPU:     AMD Ryzen 7 7735HS (Rembrandt)
  BIOS:    QBCN29WW (2026-01-15, latest available from Lenovo)

Distribution: Ubuntu 24.04.4 LTS

Loaded drivers: ideapad_laptop, lenovo_wmi_other, lenovo_wmi_helpers,
                lenovo_wmi_capdata01, lenovo_wmi_hotkey_utilities,
                sparse_keymap, platform_profile

Background:
  BIOS HotKey Mode is ON — pressing an Fx key produces the media action
  by default; Fn+Fx gives the raw function key. In normal operation,
  the media keys are emitted on multiple input devices depending on the
  function:
    * /dev/input/event2 ("AT Translated Set 2 keyboard"):
        KEY_VOLUMEUP / KEY_VOLUMEDOWN / KEY_MUTE
    * /dev/input/event5 ("Video Bus"):
        KEY_BRIGHTNESSUP / KEY_BRIGHTNESSDOWN
    * /dev/input/event6 ("Ideapad extra buttons"):
        KEY_F20 (mic mute, scancode 0x08), KEY_RFKILL (airplane, 0x0d),
        touchpad toggle, etc.

Steps to reproduce:
  1. Boot. Verify media keys work — all of brightness, volume, mic-mute,
     airplane-mode change system state when their Fx key is pressed.
  2. Suspend (s2idle). Resume after a longer idle period (short
     suspend/resume cycles do not reliably trigger the bug; in my
     experience ~15 min or more does).
  3. Press any media key.

Expected:
  System reacts as before suspend. KEY_* events are emitted on their
  respective input devices.

Actual:
  No media key does anything. Diagnostics:
    * evtest --grab /dev/input/event6: zero KEY events for any Fx press
      (confirmed via exclusive grab).
    * evtest /dev/input/event2: pressing what should be the volume-up
      key (Fx with the volume-up label) emits plain KEY_F3 (scancode
      0x3f). KEY_F1..KEY_F12 emit for the corresponding Fx positions.
      The EC is no longer translating Fx to media keycodes; it is
      forwarding raw scancodes to i8042.
  The Fn modifier is effectively a dead key — Fn+Fx and Fx produce the
  same output.

dmesg observations in broken state (attached):
  * "atkbd serio0: Failed to deactivate keyboard on isa0060/serio0"
    appears on each suspend.
  * ACPI BIOS errors at boot: AE_NOT_FOUND [\_SB.PCI0.GPP7.DEV0],
    AE_ALREADY_EXISTS [\_TZ.TZ01] (possibly unrelated, included for
    completeness).

Does not resolve the issue (all tested on this machine):
  - Writing 0 or 1 to
    /sys/bus/platform/drivers/ideapad_acpi/VPC2004:00/fn_lock
    (the fn-lock LED toggles, but event emission is unchanged).
  - rmmod/modprobe of ideapad_laptop and lenovo_wmi_hotkey_utilities.
  - Kernel parameters reported as failing by other affected users on
    the same hardware family: i8042.reset=1, i8042.nopnp,
    acpi.prefer_microsoft_guid=1.
  - Latest available BIOS (QBCN29WW, 2026-01-15).

Resolves: reboot. EC state re-syncs on cold start and media keys work
again until the next s2idle resume past the threshold.

Related user reports on the IdeaPad Slim 3 Ryzen family with the same
symptom:
  https://bbs.archlinux.org/viewtopic.php?id=310124
 
https://discussion.fedoraproject.org/t/fn-keys-stop-working-after-sleep-on-lenovo-ideapad-slim-3/95528
  https://bugs.launchpad.net/ubuntu/+bug/2114256

Attached:
  - fn-broken-dmesg.txt  — dmesg spanning broken (post-resume) state
  - fn-working-dmesg.txt — dmesg after cold boot (working state)
  - fn_lock-working.txt  — fn_lock value in working state
  - evtest-working.txt   — evtest on /dev/input/event6 showing mic-mute
                           (KEY_F20) and airplane (KEY_RFKILL) emitting
                           correctly
  - acpidump.bin         — ACPI tables (acpica-tools acpidump)

Happy to test patches, bisect, or provide additional logs (e.g.
working-state captures on event2/event5, dynamic_debug traces of
ideapad_laptop suspend/resume paths, dmesg with `no_console_suspend`).
Let me know what's most useful.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #1 from sindrehenriksen93@gmail.com ---
Created attachment 309896
  --> https://bugzilla.kernel.org/attachment.cgi?id=309896&action=edit
dmesg spanning broken (post-resume) state

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #2 from sindrehenriksen93@gmail.com ---
Created attachment 309897
  --> https://bugzilla.kernel.org/attachment.cgi?id=309897&action=edit
fn_lock sysfs value in working state

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #3 from sindrehenriksen93@gmail.com ---
Created attachment 309898
  --> https://bugzilla.kernel.org/attachment.cgi?id=309898&action=edit
evtest on event6 (mic-mute, rfkill emitting)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #4 from sindrehenriksen93@gmail.com ---
Created attachment 309899
  --> https://bugzilla.kernel.org/attachment.cgi?id=309899&action=edit
ACPI tables

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

Rong Zhang (i@rong.moe) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |i@rong.moe

--- Comment #5 from Rong Zhang (i@rong.moe) ---
(In reply to sindrehenriksen93 from comment #0)
> Loaded drivers: ideapad_laptop, lenovo_wmi_other, lenovo_wmi_helpers,
>                 lenovo_wmi_capdata01, lenovo_wmi_hotkey_utilities,
>                 sparse_keymap, platform_profile

I assume this is a firmware or EC issue in s0ix, considering that even i8042 is
broken.

Hi, could you try to blacklist (see modprobe.d (5)) all these modules and
reproduce the issue? By blacklisting them, you will not be able to use "Ideapad
extra buttons," so please just test against "AT Translated Set 2 keyboard".

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #6 from sindrehenriksen93@gmail.com ---
Tested as requested. All seven modules blacklisted:

  blacklist ideapad_laptop
  blacklist lenovo_wmi_other
  blacklist lenovo_wmi_helpers
  blacklist lenovo_wmi_capdata01
  blacklist lenovo_wmi_hotkey_utilities
  blacklist sparse_keymap
  blacklist platform_profile

`update-initramfs -u` after — without the initramfs rebuild
ideapad_laptop still loads early. Post-reboot, `lsmod` confirms none
of the seven is loaded. Testing only against /dev/input/event2 (AT
Translated Set 2 keyboard), since event5/event6 paths are gone with
these modules blacklisted.

Working state (post-boot, pre-suspend):

  volume-up   Fx press -> MSC_SCAN 0xb0  KEY_VOLUMEUP
  volume-down Fx press -> MSC_SCAN 0xae  KEY_VOLUMEDOWN
  mute        Fx press -> MSC_SCAN 0xa0  KEY_MUTE

So event2 works normally without any of these modules — the EC is
translating Fx to the E0-extended media scancodes and atkbd is
delivering them as expected.

Broken state (after s2idle resume, ~21 min suspend):

  volume-up   Fx press -> MSC_SCAN 0x3d  KEY_F3
  volume-down Fx press -> MSC_SCAN 0x3c  KEY_F2
  mute        Fx press -> MSC_SCAN 0x3b  KEY_F1

Same machine, same kernel, same blacklist still in effect. The EC has
stopped translating Fx to media scancodes and is emitting raw F-key
scancodes (0x3b..0x3d = F1..F3).

Conclusion: the regression reproduces with ideapad_laptop,
lenovo_wmi_*, sparse_keymap, and platform_profile all absent. None of
them is in the code path that breaks. Matches your firmware/EC
hypothesis.

Attaching the two evtest captures (event2, --grab):
  evtest-blacklisted-working.txt
  evtest-blacklisted-broken.txt

Happy to run further tests — e.g. dynamic_debug on the acpi/ec path
across suspend/resume, `pm_test core/platform/processor` to narrow the
phase, or acpidump/ectool snapshots in both states. Let me know what
would help most.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #7 from sindrehenriksen93@gmail.com ---
Created attachment 309919
  --> https://bugzilla.kernel.org/attachment.cgi?id=309919&action=edit
evtest on event2, all 7 modules blacklisted, pre-suspend (working)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #8 from sindrehenriksen93@gmail.com ---
Created attachment 309920
  --> https://bugzilla.kernel.org/attachment.cgi?id=309920&action=edit
evtest on event2, all 7 modules blacklisted, post-s2idle resume (broken)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #9 from Rong Zhang (i@rong.moe) ---
Thanks for testing.

I've just checked the decompiled ASL code of PNP0D80 (in SSDT4). Nothing stands
out, and the S0ix implementation seems appropriate.

The next thing that caught my eye was the "Failed to deactivate keyboard on
isa0060/serio0" error. Some devices can't handle this properly and will run
into a broken state. I am not sure whether your device falls into this
category, so please recompile the kernel using the following patch and see if
it helps.

diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index 840cdf5878dc..7f5f1d1ca265 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -250,7 +250,7 @@ static unsigned int (*atkbd_platform_scancode_fixup)(struct
atkbd *, unsigned in
  * Certain keyboards to not like ATKBD_CMD_RESET_DIS and stop responding
  * to many commands until full reset (ATKBD_CMD_RESET_BAT) is performed.
  */
-static bool atkbd_skip_deactivate;
+static bool atkbd_skip_deactivate = 1;

 static ssize_t atkbd_attr_show_helper(struct device *dev, char *buf,
                                ssize_t (*handler)(struct atkbd *, char *));

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

Mario Limonciello (AMD) (mario.limonciello@amd.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mario.limonciello@amd.com

--- Comment #10 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
This sounds most likely to be an EC bug - have you tried on Windows to see if
it happens there too?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

Daniel Gibson (metalcaedes@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |metalcaedes@gmail.com

--- Comment #11 from Daniel Gibson (metalcaedes@gmail.com) ---
I have a similar issue on an IdeaPad Slim 3 16ABR8, using Kernel 7.0 with
XUbuntu 26.04 (I'll hopefully post a separate bug report about that soon,
unless I should post all my infos here)

Here the keyboard doesn't work at all after suspend+resume, unbinding and
re-binding i8042 makes it kinda work, but the Fn keys don't work then - and
neither does the LID SWITCH.

I also get the "Failed to deactivate keyboard on isa0060/serio0" error.

Adding i8042.nopnp to the kernel commandline helps a little bit: Then after
suspend+resume most of the keyboard still works, but like in the other case the
Fn keys and the lid switch don't.

Anyway, one thing that makes the issue go away here (but is no acceptable
solution) is to blacklist the amd_pmc kernel module, or unload it before
suspend.
Then after suspend+resume everything works as expected, but the downside is
that the laptop draws more power while suspended (measured 1.4W on the
wallplug, when amd_pmc is loaded it's 0.4W).

Could you check if `rmmod amd_pmc` before suspend, while the keyboard still is
in working order, works around the issue for you as well?

Regarding Windows, I didn't test it that much (and replaced it with Linux), but
I don't remember seeing those issues - I'm not 100% sure I actually had the
laptop suspended there, but I think so (Win11 does that automatically when
closing the lid, right?)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #12 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
Unloading amd pmc will prevent hardware sleep; so that's no surprise to me. It
also would mean EC never sees the sleep signal and thus would likely never go
to a low power state either.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #13 from Daniel Gibson (metalcaedes@gmail.com) ---
I guess this at least rules out that the functions in the involved drivers
(i8042, atkbd, ...?) that are called when suspending and resuming confuse the
keyboard controller.

Should I create an additional report with all my infos (dmesg, `amd-s2idle
test` output, etc) or post this here?
My IdeaPad has a Ryzen 7430U which is Zen3/Barcelo R and uses DDR4 RAM while
the one of this report is a Ryzen 7735H (Zen3+/Rembrandt R with DDR5 RAM)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #14 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
Well not necessarily does it rule it out. Maybe Windows does a different
sequence at suspend resume to 8042 and that's the root of the problem.

Given the similar symptoms I don't see a problem linking these together for
now.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #15 from Daniel Gibson (metalcaedes@gmail.com) ---
Created attachment 309930
  --> https://bugzilla.kernel.org/attachment.cgi?id=309930&action=edit
Daniels dmesg when running suspend manually, see XXX comments

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #16 from Daniel Gibson (metalcaedes@gmail.com) ---
Created attachment 309931
  --> https://bugzilla.kernel.org/attachment.cgi?id=309931&action=edit
Daniels dmesg when running suspend manually, with patched ACPI table

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #17 from Daniel Gibson (metalcaedes@gmail.com) ---
Created attachment 309932
  --> https://bugzilla.kernel.org/attachment.cgi?id=309932&action=edit
Daniels amd-s2idle report

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #18 from Daniel Gibson (metalcaedes@gmail.com) ---
Created attachment 309933
  --> https://bugzilla.kernel.org/attachment.cgi?id=309933&action=edit
Daniels ACPI tables, unpatched

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #19 from Daniel Gibson (metalcaedes@gmail.com) ---
Created attachment 309934
  --> https://bugzilla.kernel.org/attachment.cgi?id=309934&action=edit
Daniels patched ACPI table

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #20 from Daniel Gibson (metalcaedes@gmail.com) ---
Created attachment 309935
  --> https://bugzilla.kernel.org/attachment.cgi?id=309935&action=edit
Daniels lshw

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #21 from Daniel Gibson (metalcaedes@gmail.com) ---
Created attachment 309936
  --> https://bugzilla.kernel.org/attachment.cgi?id=309936&action=edit
Daniels /proc/interrupts and lsmod output

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #22 from Daniel Gibson (metalcaedes@gmail.com) ---
Alright, thanks :)

So here a longer post about what I'm seeing on my machine.
Note that unlike Sindre I see these issues even if the laptop has only been
suspended for a few seconds (I always wait until an indicator LED on the side
starts flashing instead of being on constantly).

After booting or rebooting the system, everything works as expected: The F-keys
do their thing (mute audio or whatever), when combining them with Fn they
behave like normal F1, F2 and so on and the lid switch also works, so when
closing the laptop it suspends (when configured that way).

However after suspend+resume, the keyboard doesn't work anymore, and neither
does the lid switch.
Running `echo i8042 | sudo tee /sys/bus/platform/drivers/i8042/unbind`
and then `echo i8042 | sudo tee /sys/bus/platform/drivers/i8042/bind`
makes the keyboard mostly work again, except that the Fn keys don't work as
intended (pressing F1 and Fn+F1 both report plain F1, not Mute) and the lid
switch still doesn't work.

Adding "i8042.nopnp" to the kernel commandline helps a bit: When it's set the
keyboard works after suspend+resume without unbinding/rebinding it, but the
Fn-keys and the lid switch are broken after resuming, just like before.


In dmesg I noticed a message "ACPI BIOS Error (bug): Could not resolve symbol
[\_SB.PC00.LPCB.EC0.SNTM], AE_NOT_FOUND (20230628/psargs-330)" during wakeup.
After decompiling the ACPI tables the I saw that this indeed doesn't exist, but
"\_SB.PCI0.LPC0.EC0.SNTM" does, so I patched the call accordingly. Didn't seem
to make a difference, though, apart from getting rid of that ACPI BIOS Error. 


When I tried to run `amd-s2idle test`, it refused because "GPIO interrupt is
not served" It suggests loading the i2c-hid-acpi kernel module, but it was
already loaded.
So I checked `/sys/kernel/debug/gpio` and it contained the line

> #89   🔥 😷|     ↓|  level|    |   |     |  |    |  ↓ |input  ↓|        
> |0x10240b00

Apparently that fire emoji means that this GPIO interrupt is not served (it's
the only line with fire).
`gpioset -c gpiochip0 -p 2m 89=1` makes that issue temporarily go away and
allows running amd-s2idle.

GPIO Line 89 seems to belong to the touchpad, when setting dyndbg='module
pinctrl_amd +p' I get lots of lines like
[   25.273930] GPIO 9 is active: 0x10141b00
[   25.273967] GPIO 89 is active: 0x10240b00
[   25.280561] GPIO 9 is active: 0x10141b00
[   25.280585] GPIO 89 is active: 0x10240b00
in dmesg whenever I touch the touchpad.


Rarely they keys and lid switch still work after resume, usually in that case
there's a message like
[   54.421557] amd_pmc AMDI0005:00: Last suspend didn't reach deepest state
in dmesg. When that happens the next suspends behave the same (and still yield
the message), until rebooting.

Once or twice things "worked" without showing that "didn't reach deepest state"
message; unfortunately in those cases I didn't check power consumption on the
wattmeter the laptop's power adapter is plugged into, so I can't say if it was
a proper suspend or not.

I attached a lot of stuff, run with Kernel 7.0 from Ubuntu's mainline repo (my
own build has lots of changes for additional debugprints by now) and mostly
with unpatched (original) ACPI tables, except for
dg-16ABR8-dmesg_patched_acpi.txt and lshw which are with the patched ACPI table
to get rid of the aforementioned "ACPI BIOS Error".
dg-16ABR8-ssdt14-mod.dsl is the source of the modified ACPI table.


Is there any more information I can provide, or things I could try?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #23 from Daniel Gibson (metalcaedes@gmail.com) ---
Some more observations:

- `cat /proc/acpi/button/lid/LID/state` always returns the correct state, so it
seems like the lid switch still works and can be queried after suspend, it just
doesn't seem to send events anymore
- When pressing capslock on an external keyboard, usually the internal
keyboards LED is adjusted accordingly and dmesg tells me that the expected
bytes are sent and received by i8042: ed -> i8042 (command for setting LEDs);
fa <- i8042 (ACK); 04 -> i8042 (parameter of the command, bits for set LEDs);
fa <- i8042 (ACK)
- Pressing a key on the internal keyboard still wakes the machine from suspend,
even if the the keyboard otherwise doesn't work. Even for a second suspend
where the keyboard was already broken when suspending.

Maybe pressing a key (or operating the lid switch) just doesn't send an
interrupt anymore after suspend, despite otherwise working? 
This seems to be the case for the lid switch, no idea if the keys do anything
internally, so for that part it's more of a theory.

Furthermore: I can make the "Failed to deactivate keyboard on isa0060/serio0"
message often go away by making __ps2_command() in drivers/input/serio/libps2.c
use higher timeouts for 0x00f5 (ATKBD_CMD_RESET_DIS), like it already does for
PS2_CMD_RESET_BAT. But that doesn't change the fact that the keyboard doesn't
work after resume.
When the `ps2_do_sendbyte(ps2dev, command & 0xff, timeout, 2);` call in that
function fails, it returns -5 (-EIO); I think the problem is that no ACK (0xfa)
was received within the timeout.

So it seems like after resume the i8042 interrupt handler is only called for
direct replies to commands sent to the keyboard (I think I've only seen ACKs)
and even then it:
- sometimes is later than expected
- sometimes lacks data ("[  363.566845] i8042: [363145] Interrupt 1, without
any data") 
- sometimes is missing entirely (no ACK at all after a command) 


By the way, there are several reports of similar/related issues, some of them
resolved, see also https://bugzilla.kernel.org/show_bug.cgi?id=221217#c2

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #24 from sindrehenriksen93@gmail.com ---
I almost forgot — reading through these comments made me realise I also
experience the complete keyboard failure, not just the Fn key issue. After
resume the internal keyboard stops responding entirely. I've been running a
systemd-sleep hook that rescans serio0 on resume to work around it — might be
useful for you, Daniel:

#!/bin/sh
case "$1" in
  post)
    echo -n "rescan" > /sys/devices/platform/i8042/serio0/drvctl 2>/dev/null
    echo -n "1" > /sys/bus/pci/rescan 2>/dev/null
    echo -n "serio0" > /sys/bus/serio/drivers/atkbd/bind 2>/dev/null
    ;;
esac

Install to /usr/lib/systemd/system-sleep/ with chmod +x. Restores basic
keyboard function after resume, but not Fn key translation.

On the amd_pmc angle — I've seen similar "fixes" floating around, but they're
not really viable given the battery impact.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #25 from Daniel Gibson (metalcaedes@gmail.com) ---
Thanks, but I can get the same effect with the `i8042.nopnp` kernel commandline
option (`GRUB_CMDLINE_LINUX="i8042.nopnp"` in /etc/default/grub, then run
`update-grub`) :)

Apart from the Fn key issue I find the lid switch issue quite annoying - I'd
really like the system to suspend when the lid is closed.

Does your lid switch also stop working after the first suspend+resume?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #26 from Daniel Gibson (metalcaedes@gmail.com) ---
Regarding Windows, I thought a bit about it and remembered that I was annoyed
that Windows went to sleep without being told to, even when running a command..
so suspend+resume worked, if the keyboard had completely failed afterwards I
would have noticed.
Can't say with absolute certainty that I would've noticed broken Fn keys, as I
usually enabled Fn-lock to get the real F1-F12 keys.. but I googled the issue
and even when explicitly specifying "Windows" or "Win11" in the query I only
got results for the problem on Linux (or generic keyboard issues unrelated to
suspend), so I guess it doesn't happen there.

@Mario: However, if it'd really help, I could put Windows back on the machine
for testing. Especially if you want me to run tools to log the ACPI and PS/2
events or whatever to figure out what Windows does differently to make it work
- if such tools exists and you can point me towards a tutorial or something
that describes how to use them for this purpose :)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #27 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
Yes as you noted for Windows it's important to note Windows needs to get into
what is called HW DRIPS.  Windows kernel waits some time for both software and
hardware to quiesce before activating HW DRIPS.  This is what Linux does
immediately when you have amd-pmc loaded.

So there ABSOLUTELY are some timing differences for Windows and Linux; and it
wouldn't be the first time timing exposed a bug; but it's shooting in the dark
to assign blame on timing without evidence of traces of activity to the EC.

If you DO want to shoot in the dark and try to change timing (for example delay
HW sleep) you can modify this:

https://github.com/torvalds/linux/commit/9f5595d5f03fd4dc640607a71e89a1daa68fd19d

Just drop the conditional there or add an extra msleep() call.

---

Regarding getting EC and PS2 traffic from Windows - I completely agree this
would be useful for this issue, but I don't know how to do this, maybe some
others do or you can see if some of the LLMs can help with this.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #28 from Daniel Gibson (metalcaedes@gmail.com) ---
> If you DO want to shoot in the dark and try to change timing ...

Thanks, this was a great idea!

If I add msleep(1500); (1000 is not enough) to both amd_pmc_s2idle_check() and
amd_pmc_s2idle_restore(), everything works as intended \o/

... at least in my patched kernel that has some other changes like longer
waiting for ACKs in __ps2_command(), I yet have to try the vanilla 7.0 source
with just these changes.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #29 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
Woah! Well play with it and compare EC and PS2 traffic in both cases. Sounds
like we have a race condition after all.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #30 from Daniel Gibson (metalcaedes@gmail.com) ---
Created attachment 309943
  --> https://bugzilla.kernel.org/attachment.cgi?id=309943&action=edit
First draft of a patch for amd_pmc, for testing

Here's a simple patch adding these sleeps, for testing - @Sindre, please check
if it fixes the problem on your machine :)

Right now those sleeps are always done, I'll make them optional via a module
option and maybe a hardware quirk list later.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #31 from Daniel Gibson (metalcaedes@gmail.com) ---
> Woah! Well play with it and compare EC and PS2 traffic in both cases.

How do I get the EC traffic, besides logging the functions in amd_pmc?

My understanding is that these functions are pretty much the last thing
happening before suspend / after resume, so probably not much should be
happening?

The PS2/i8042/atkbd traffic isn't much different, except of course after resume
it starts a bit later now, and the functions called after resume (resetting the
controller etc) succeed without any additional hacks in atkbd or PS/2 code.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #32 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
> My understanding is that these functions are pretty much the last thing
> happening before suspend / after resume, so probably not much should be
> happening?

Turn on dynamic debug for the ACPI EC module in drivers/acpi/ec.c.

> The PS2/i8042/atkbd traffic isn't much different, except of course after
> resume it starts a bit later now, and the functions called after resume
> (resetting the controller etc) succeed without any additional hacks in atkbd
> or PS/2 code.

OK - more likely EC then.

> Right now those sleeps are always done, I'll make them optional via a module
> option and maybe a hardware quirk list later.

How about if you just do the 2.5s one every time on way down, is that good
enough?  It would be a lot easier to quirk (you can just add a new condition).

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #33 from Daniel Gibson (metalcaedes@gmail.com) ---
> How about if you just do the 2.5s one every time on way down, is that good
> enough?

Yes, turns out it is. Weird that sleeping before and after suspend for a
shorter time and sleeping only before suspend for a longer time have the same
effect.

I'm currently comparing the dmesg output of the broken case and the working one
(with sleeping 2.5s before suspend).
I have nothing definite to share yet, need to do these things again and this
time make sure to use the same way to wake the machine so they can be compared
easier.

But one thing that's very noticeable is that on resume there are *a lot* more
messages from EC, especially right before "PM: resume of devices complete after
1518.040 msecs" and right after "PM: suspend exit".

Once I have better comparable logs I'll share them here

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #34 from Daniel Gibson (metalcaedes@gmail.com) ---
Created attachment 309944
  --> https://bugzilla.kernel.org/attachment.cgi?id=309944&action=edit
dmesg output with EC logging, broken case

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #35 from Daniel Gibson (metalcaedes@gmail.com) ---
Created attachment 309945
  --> https://bugzilla.kernel.org/attachment.cgi?id=309945&action=edit
dmesg output with EC logging, fixed case

Here's the dmesg output for the broken case and the one where
amd_pmc_s2idle_check() sleeps for 2.5s, including some comments in them about
what's different

(I removed most lines that were logged while booting to keep the size
manageable, and they should be the same in both cases anyway)

Note that they contain some nonstandard messages from amd_pmc functions where I
just log when they start and return.

While suspending there aren't any visible differences, apart from
amd_pmc_s2idle_check() taking longer, of course.

When resuming there are lots of EC events in the fixed case that just don't
happen at all in the broken case.
Particularly, right before the PM: resume of devices complete after ..."
message, the fixed case has

 [   53.362362] ACPI: EC: IRQ (1)
 [   53.362372] ACPI: EC: EC_SC(R) = 0x20 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=0
 [   53.362382] ACPI: EC: Polling enabled
 [   53.362385] ACPI: EC: Command(QR_EC) submitted/blocked

and so on, which is missing entirely in the broken case.
See the attached dmesg_sleep_2.5s_before_suspend.txt for details


I found it useful to compare these logs with the "meld" tool, where I have
added a custom text filter with regex pattern "^\[[^]]+\] " so the timestamps
are ignored when comparing lines.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

Daniel Gibson (metalcaedes@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #309943|0                           |1
        is obsolete|                            |

--- Comment #36 from Daniel Gibson (metalcaedes@gmail.com) ---
Created attachment 309946
  --> https://bugzilla.kernel.org/attachment.cgi?id=309946&action=edit
revised patch, still rough, please test (now only sleeping before suspend)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #37 from Daniel Gibson (metalcaedes@gmail.com) ---
One thing from the dmesg messages of the broken case that might be noteworthy:
Within the last few lines, after "PM: suspend exit", are the following two
lines
  [   43.693610] ACPI: EC: IRQ (1)
  [   43.693623] ACPI: EC: EC_SC(R) = 0x40 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=0
(no more ACPI: EC: lines after that)

In the non-broken case the second line looks like:
  [   54.644940] ACPI: EC: EC_SC(R) = 0x20 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=0
and it's followed by many more "ACPI: EC:" lines.

I looked at ec.c, and "EC_SC(R) = 0x40" means that acpi_ec_read_status() has
read that value, and most probably advance_transaction() is trying to handle
it.
However, 0x40 is a case that is not handled by the code at all.

0x20 is ACPI_EC_FLAG_SCI, and according to the ACPI specification (which call
it "SCI_EVT") it "Indicates SCI event is pending (requesting SCI query)" 
(https://uefi.org/specs/ACPI/6.5_A/12_Embedded_Controller_Interface_Specification.html)

0x40 doesn't have a constant in ec.c, but the specification says it's "SMI_EVT"
which "Indicates SMI event is pending (requesting SMI query).", where "SMI"
apparently means "system management interrupt handler", whatever that is.

Is it possible that handling this case (instead of ignoring it) would cause the
problem to be fixed somehow?
Or should 0x40 just not happen there and indicates a bug in the EC?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #38 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
Created attachment 309954
  --> https://bugzilla.kernel.org/attachment.cgi?id=309954&action=edit
patch to force clear EC events on resume

FWIW - I passed your logs and this bug through Claude + the kernel
review-prompts skill (https://github.com/masoncl/review-prompts) with a local
kernel checkout and it at least agrees that this is primarily an EC FW timing
bug.

----
  1. EC Interrupt Blocking: When acpi_ec_enter_noirq() is called during
suspend, the EC driver switches to busy polling mode (ec->busy_polling = true)  
  2. Critical Window: Between EC interrupt blocking and actual suspend entry,
the EC firmware needs time to:
    - Complete any in-flight transactions in polling mode                       
    - Flush internal state                                                      
    - Save hotkey handler state                                                 
    - Prepare for suspend                                                       
  3. The Race:                                                                  
    - Without delay: EC interrupts blocked → system suspends almost immediately
→ EC firmware doesn't complete state save → On resume, EC loses hotkey event
state                                                                           
    - With 2.5s delay: EC interrupts blocked → 2.5s in polling mode → EC
firmware completes state transitions → system suspends → On resume, EC restores
hotkey state correctly                                                          
  4. Why SCI_EVT differs:                                                       
    - In the broken case, the EC firmware lost track of hotkey state during
suspend because it was rushed                                                   
    - In the working case, the EC had time to properly save state and restore
it, so SCI_EVT=1 appears naturally on resume                                    
----

But - that being said I pushed the LLM a little bit more and wonder if maybe
draining the events on resume would help.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #39 from Daniel Gibson (metalcaedes@gmail.com) ---
Created attachment 309955
  --> https://bugzilla.kernel.org/attachment.cgi?id=309955&action=edit
dmesg with the draining EC patch

I tried the LLM's patch, it doesn't work - the keyboard doesn't work after
suspend, see also the attached dmesg, which is incomplete because apparently
this is also executed during boot and already spams so many messages into dmesg
that its running over.

One thing that's interesting is that the "X stale EC events cleared" message is
never shown. I added some more prints and apparently after resume in
acpi_ec_clear() acpi_ec_submit_query(ec) is called exactly once - and never
returns.

  [   45.771402] ACPI: EC: acpi_ec_clear()
  [   45.771402] ACPI: EC: acpi_ec_clear(): submitting query 0
  [   45.771404] ACPI: EC: 2: Increase command
  [   45.771406] ACPI: EC: Command(QR_EC) started

"submitting query 0" is printed at the beginning of the "for (i = 0; i <
ACPI_EC_CLEAR_MAX; i++) {" loop

There is no "acpi_ec_clear(): submitting query 1" message for the next loop
iteration, and there is no "X stale EC events cleared" message that would
indicate that this first call has returned.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #40 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
Okay. Well if you decide you want to just jump to a quirk I'm not against that.
It should be pretty straightforward to add your DMI info and run this code
path.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #41 from Daniel Gibson (metalcaedes@gmail.com) ---
Yeah, I'll do that. Would be good to have feedback from people with slightly
different versions of the IdeaPad Slim 3 that have similar issues, to see if
the fix works for them as well, and maybe even try to find a way to match all
of those.

(In the end, if there's an AMD-based IdeaPad Slim 3 that doesn't need the
quirk, delaying suspend for 2.5s doesn't hurt anyone)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

Daniel Gibson (metalcaedes@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #309946|0                           |1
        is obsolete|                            |

--- Comment #42 from Daniel Gibson (metalcaedes@gmail.com) ---
Created attachment 309957
  --> https://bugzilla.kernel.org/attachment.cgi?id=309957&action=edit
patch that adds sleeping for 2.5s before suspend for IdeaPad Slim 3 devices or
when setting delay_suspend=1

Now I'm using the existing quirks mechanism (fwbugs_list[]) to enable the
workaround on most devices that identify as LENOVO IdeaPad Slim 3.

It can also be explicitly enabled or disabled with a module argument: 
  amd_pmc.delay_suspend=1
to enable, 0 to disable (even if device is detected as affected) or -1 (the
default) to let fwbugs_list[] decide.

If this is used, a message like "Delaying suspend by 2.5s to avoid platform
bug" or "Delaying suspend by 2.5s because delay_suspend=1" is printed to dmesg,
so one can easily checked if it is active or not.

@Sindre: Please test this, and please disable any other workarounds for this
issue that you may have on your system while testing :)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #43 from sindrehenriksen93@gmail.com ---
Nice! Tested on my IdeaPad Slim 3 14ARP10 (Ryzen 7735H) with the keyboard-reset
workaround disabled. DMI match fires correctly ("Delaying suspend by 2.5s to
avoid platform firmware bug" in dmesg).

- Short suspend + resume: keyboard works (previously broke without the
workaround)
- 15+ min suspend + resume: Fn keys work (previously broke consistently)

Both issues fixed by the patch.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #44 from Daniel Gibson (metalcaedes@gmail.com) ---
Great, thank you very much for the feedback!
Good to know that despite the different platform generations the problems have
the same cause (or at least can be avoided with the same workaround).

I guess I should try to get it into the kernel now

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #45 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
As a general statement - it is probably too broad to cover all 'Ideapad Slim 3'
DMI matches.

If they fix the issue in next year's model, then it would still penalize next
year's model with the 2.5s delay on sleep entry.

So if possible it would be better to follow the approach all the other DMI
matches do for Lenovo.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #46 from Daniel Gibson (metalcaedes@gmail.com) ---
Thanks for the feedback!

Do you think matching the whole series (that seem to share the same BIOS, at
least for the different screen sizes of 16ABR8) is ok, like

  {
        .ident = "IdeaPad Slim 3",
        .driver_data = &quirk_s2idle_need_suspend_delay,
        .matches = {
                DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
                /* match all IdeaPad Slim 3 models of the ABR8
                   generation, like 16ABR8, 15ABR8, ... */
                DMI_MATCH(DMI_PRODUCT_FAMILY, "IdeaPad Slim 3"),
                DMI_MATCH(DMI_PRODUCT_FAMILY, "ABR8")
        }
  },

(and the same for Sindre's "ARP10" series)?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #47 from Daniel Gibson (metalcaedes@gmail.com) ---
Oh, one thing I forgot to ask, in the ideapad_laptop kernel module's modinfo
I've seen
>  parm: allow_v4_dytc:Enable DYTC version 4 platform-profile support. If you
>  need this please report this to: platform-driver-x86@vger.kernel.org (bool)

presumably so the users device can be added to the quirks list, do you think I
should do the same here?
What would be an appropriate address to list there?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #48 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
Try using DMI_PRODUCT_NAME like the other Lenovo systems.  This should match
whole generations hopefully.

As for the other ideapad-laptop question, you need to talk to the authors of
that module.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #49 from Daniel Gibson (metalcaedes@gmail.com) ---
> Try using DMI_PRODUCT_NAME like the other Lenovo systems.  This should match
> whole generations hopefully.

As far as I can tell it doesn't. For my 16ABR8 it's 82XR, the dmesg log of
https://bugzilla.kernel.org/show_bug.cgi?id=220521 mentions 82XM, which seems
to be 15ABR8 (says
https://download.lenovo.com/consumer/mobiles_pub/ideapad_slim_3_hmm.pdf), so
presumably the last char of the product name is the screen size.

I guess matching "IdeaPad Slim 3" + "ABR8" is safer than matching "82X".

> As for the other ideapad-laptop question, you need to talk to the authors of
> that module.

Sorry, I didn't mean to add anything to that module. It was just an example of
a module having a parameter that works around hardware bugs with a description
that explicitly asks users to report their hardware so it can be added to the
quirks list (or at least that's my assumption why they ask for it).

My question is: Do you think

  static int delay_suspend = -1;
  module_param(delay_suspend, int, 0644)
  MODULE_PARM_DESC(delay_suspend,
        "Delays s2idle by 2.5 seconds to work around buggy ECs, often causing
keyboard issues after suspend. "
        "0: don't delay, 1: do delay, -1 (default): let amd_pmc decide. "
        "If you need this please report this to:
platform-driver-x86@vger.kernel.org");

makes sense?
(I guess it would be the same e-mail address, as this bugreport goes to that
list as well.)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #50 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
> My question is: Do you think makes sense?

Ah I see.  Module parameters are usually frowned upon for debugging purposes. 
How about a debugfs file entry?

This would be just as functional; but arguably more usable.  For example
someone could boot a (future) live media and change just that debugfs value to
activate it.

> I guess matching "IdeaPad Slim 3" + "ABR8" is safer than matching "82X".

So both a DMI_PRODUCT_NAME + DMI_PRODUCT_FAMILY match?

Sounds good to me.  And we can always change this if we discover it's an
untenable approach.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #51 from Daniel Gibson (metalcaedes@gmail.com) ---
> Module parameters are usually frowned upon for debugging purposes.

It's not just for debugging, it works around the issue for devices that are
affected but not (yet) on the quirks list. So users of such devices can add it
to their kernel commandline so they can use the device - like all those i8042
parameters or "acpi.prefer_microsoft_dsm_guid" in the past.
I think this is more userfriendly (and a way familiar to many users) than
having them write an init script (or systemd unit or whatever) that writes some
debugfs option on boot?

> So both a DMI_PRODUCT_NAME + DMI_PRODUCT_FAMILY match?

After looking at
https://download.lenovo.com/consumer/mobiles_pub/ideapad_slim_3_hmm.pdf more
closely, it seems like *ABR8 and 82X* are not that closely related, it lists
several 82X* "machine types" that are not *ABR8, e.g. "IdeaPad Slim 3 14IAN8 1"
(82XA) or "IdeaPad Slim 3 16IRU8" (82X8).

From downloading a BIOS-update for my machine I know that the same BIOS is used
for several (probably all) Slim 3 *ABR8 devices, so it seems like this part of
the product family is the best way to match those devices:
https://pcsupport.lenovo.com/de/de/products/laptops-and-netbooks/ideapad-s-series-netbooks/ideapad-slim-3-16abr8/downloads/ds560742?category=BIOS

OTOH that BIOS is also for the "IdeaPad Slim 5 Light 14ABR8" (82XS; note it's
"Slim 5" this time) (-:

Hooray for consistency!

IDK, I'll try to find out if it's feasible to match each device individually
after all, if I can find all the DMI_PRODUCT_FAMILY values of the devices using
either the same BIOS as mine or as Sindre's.

(I fear in the end it'll turn out that at least all Zen3 and Zen3+ IdeaPads are
affected anyway, but who knows - while many people have complained about this
bug online in the last years, a lot of them have only specified "IdeaPad Slim
3", and I don't think there's a good way to DMI-match the CPU generations
anyway)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #52 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
Right - I don't disagree on the utility, but it's a relatively high bar to add
a new module parameter especially when it's driver specific.

I would say at a minimum you should make the parameter a secondary patch in
your series if you keep it so it doesn't block the rest of the work on the
quirk.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

Daniel Gibson (metalcaedes@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #309957|0                           |1
        is obsolete|                            |

--- Comment #53 from Daniel Gibson (metalcaedes@gmail.com) ---
Created attachment 309975
  --> https://bugzilla.kernel.org/attachment.cgi?id=309975&action=edit
patch adding (only) the quirk to amd_pmc

Thanks for the suggestion :)

@Sindre: I'm trying to create the commits in the proper format, with
Reported-by etc.
Are you ok with being listed as "Reported-by: Sindre Henriksen
<sindrehenriksen93@gmail.com>" and a similar "Tested-by:" line?

Can you test the new patch? I changed the DMI matches.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #54 from Daniel Gibson (metalcaedes@gmail.com) ---
Created attachment 309976
  --> https://bugzilla.kernel.org/attachment.cgi?id=309976&action=edit
patch adding the delay_suspend parameter to amd_pmc

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #55 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
re comment #53:

Can you just use "82X" and "83K" for the product name to cover all those
systems?  I think that should cover them all with just two quirks.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #56 from Daniel Gibson (metalcaedes@gmail.com) ---
There are other AMD-based Lenovo devices with those product family values, like
"IdeaPad Flex 5 14ABR8" (82XX) or "IdeaPad Slim 3 14AMN8" (82XN) or "Lenovo LOQ
16APH8" (82XU) or "Yoga Pro 7 14AKP10" (83KG) or "Ideapad 5 2-in-1 14AKP10"
(83KT) and I don't know if they have this bug as well.

Searching for those devices +linux +suspend indicates that not all of them have
this problem (or it has never been reported anywhere).

For 82XU I found a similar report
(https://bbs.archlinux.org/viewtopic.php?id=292867), for 83KT one that might be
related but not sure
(https://forum.manjaro.org/t/laptop-will-not-wake-from-suspend/183975)

Then again, delaying suspend for 2.5s is not something that you notice unless
you know it - I think the power LED even starts blinking before that time is
over.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #57 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
Yeah; It's hard to know if people just haven't tested those systems with Linux
or if they don't have the bug.

Good point it's only 2.5s and you won't notice unless you're looking for it.  I
can be convinced either way here, you can make the call when you submit the
patch.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #58 from Daniel Gibson (metalcaedes@gmail.com) ---
> Yeah; It's hard to know if people just haven't tested those systems with
> Linux or if they don't have the bug

Yeah.. for the devices that are affected, like mine, I also found reports where
people were happy and marked the issue as "resolved" in the forums when they
had a workaround that still left the Fn-keys broken (and I guess they never
realized the lid switch doesn't work), or even with "I disabled suspending
completely and always shut down now, as a workaround" - "great, solved, closing
topic" -_-

> you can make the call when you submit the patch.

Maybe I'll try to get the patch in matching all of 82X and 83K - I think the
annoyance of a broken keyboard after suspend is *much* bigger than delaying
sleep by 2.5s when it *maybe* wasn't really necessary.
I can still go back to matching the individual devices if the review requests
it.


Thank you very much for your advice, it's much appreciated!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

Mario Limonciello (AMD) (mario.limonciello@amd.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|drivers_platform_x86@kernel |metalcaedes@gmail.com
                   |-bugs.osdl.org              |

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.