Hi, On 3/16/22 14:37, Limonciello, Mario wrote: > [Public] > >>> Just FWIW this fix that was backported to stable also fixed keyboard >>> wakeup from s2idle on a number of HP laptops too. I know for sure that >>> it fixed it on the AMD versions of them, and Kai Heng Feng suspected it >>> will also fix it for the Intel versions. So if there is another commit >>> that can be backported from 5.17 to make it safer for the other systems, >>> I think we should consider doing that to solve it too. >> >> There is a series of ACPI EC driver commits that are present in >> 5.17-rc, but have not been included in any "stable" series: >> >> befd9b5b0c62 ACPI: EC: Relocate acpi_ec_create_query() and drop >> acpi_ec_delete_query() >> c33676aa4824 ACPI: EC: Make the event work state machine visible >> c793570d8725 ACPI: EC: Avoid queuing unnecessary work in >> acpi_ec_submit_event() >> eafe7509ab8c ACPI: EC: Rename three functions >> a105acd7e384 ACPI: EC: Simplify locking in acpi_ec_event_handler() >> 388fb77dcf97 ACPI: EC: Rearrange the loop in acpi_ec_event_handler() >> 98d364509d77 ACPI: EC: Fold acpi_ec_check_event() into >> acpi_ec_event_handler() >> 1f2350443dd2 ACPI: EC: Pass one argument to acpi_ec_query() >> ca8283dcd933 ACPI: EC: Call advance_transaction() from >> acpi_ec_dispatch_gpe() >> >> It is likely that they prevent the problem exposed by the problematic >> commit from occurring, but I'm not sure which ones do that. Some of >> them are clearly cosmetic, but the ordering matters. > > Hans, > > Do you think you could get one of the folks who reported this regression to do > a bisect to see which one "fixed" it? We already know which commit is causing the regression. As Rafael already said the question is why things are not broken in 5.17 and that is not a straight forward bisect. So figuring this out is going to be a lot of work and I'm not sure of that it is worth it. I certainly don't have time to help users with debugging this. > If we get lucky we can come down to > some smaller hunks of code that can come back to stable instead of reverting. 5.17 is almost done and in a couple of weeks Fedora (and Arch and other distros tracking the mainline kernel) will move to 5.17 resolving the wakeup by keyboard issue not working there. 5.16 is not a LTS kernel, so for other distros we would at a minimum figure out what needs to be backported to make things work with 5.15 making the delta / set of possible patches we need even bigger. So as already said IMHO this is not worth it, at least assuming that nothing bad happens when attempting wakeup by keyboard, iow it just does not work and does not put the laptop in some bad state? Regards, Hans
