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

[bugzilla-daemon@kernel.org]

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.