After commit 936e4d49ecbc ("Input: atkbd - skip ATKBD_CMD_GETID in
translated mode") not only the getid command is skipped, but also
the de-activating of the keyboard at the end of atkbd_probe(), potentially
re-introducing the problem fixed by commit be2d7e4233a4 ("Input: atkbd -
fix multi-byte scancode handling on reconnect").
Make sure multi-byte scancode handling on reconnect is still handled
correctly by not skipping the atkbd_deactivate() call.
Fixes: 936e4d49ecbc ("Input: atkbd - skip ATKBD_CMD_GETID in translated mode")
Tested-by: Paul Menzel <email address hidden>
Signed-off-by: Hans de Goede <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Dmitry Torokhov <email address hidden>
(cherry picked from commit 9cf6e24c9fbf17e52de9fff07f12be7565ea6d61)
Signed-off-by: Aaron Ma <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>
2b25a5a...
by
Hans de Goede <email address hidden>
Input: atkbd - skip ATKBD_CMD_SETLEDS when skipping ATKBD_CMD_GETID
After commit 936e4d49ecbc ("Input: atkbd - skip ATKBD_CMD_GETID in
translated mode") the keyboard on Dell XPS 13 9350 / 9360 / 9370 models
has stopped working after a suspend/resume.
The problem appears to be that atkbd_probe() fails when called
from atkbd_reconnect() on resume, which on systems where
ATKBD_CMD_GETID is skipped can only happen by ATKBD_CMD_SETLEDS
failing. ATKBD_CMD_SETLEDS failing because ATKBD_CMD_GETID was
skipped is weird, but apparently that is what is happening.
Fix this by also skipping ATKBD_CMD_SETLEDS when skipping
ATKBD_CMD_GETID.
Fixes: 936e4d49ecbc ("Input: atkbd - skip ATKBD_CMD_GETID in translated mode")
Reported-by: Paul Menzel <email address hidden>
Closes: https://<email address hidden>/
Closes: https://bbs.archlinux.org/viewtopic.php?pid=2146300
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218424
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2260517
Tested-by: Paul Menzel <email address hidden>
Cc: <email address hidden>
Signed-off-by: Hans de Goede <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Dmitry Torokhov <email address hidden>
(cherry picked from commit 683cd8259a9b883a51973511f860976db2550a6e)
Signed-off-by: Aaron Ma <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>
c4dc243...
by
John Harrison <email address hidden>
A failure to load the HuC is occasionally observed where the cause is
believed to be a low GT frequency leading to very long load times.
So a) increase the timeout so that the user still gets a working
system even in the case of slow load. And b) report the frequency
during the load to see if that is the cause of the slow down.
Also update the similar code on the GuC load to not use uncore->gt
when there is a local gt available. The two should match, but no need
for unnecessary de-referencing.
Signed-off-by: John Harrison <email address hidden>
Reviewed-by: Daniele Ceraolo Spurio <email address hidden>
Link: https://patchwork.freedesktop<email address hidden>
(cherry picked from commit a797099562267ebb281acd59750f1a8dbba36eef)
Signed-off-by: Chris Chiu <email address hidden>
Acked-by: Kai-Heng Feng <email address hidden>
Acked-by: Aaron Ma <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>
82c4916...
by
Vinay Belgaumkar <email address hidden>
GuC load takes longer sometimes due to GT frequency not ramping up.
Add perf_limit_reasons to the existing warn print to see if frequency
is being throttled.
The following error can be observed at boot:
[ 3.717920] ACPI Error: No handler for Region [SYSI] (00000000ab9e62c5) [IPMI] (20230628/evregion-130)
[ 3.717928] ACPI Error: Region IPMI (ID=7) has no handler (20230628/exfldio-261)
[ 3.717936] No Local Variables are initialized for Method [_GHL]
[ 3.717938] No Arguments are initialized for method [_GHL]
[ 3.717940] ACPI Error: Aborting method \_SB.PMI0._GHL due to previous error (AE_NOT_EXIST) (20230628/psparse-529)
[ 3.717949] ACPI Error: Aborting method \_SB.PMI0._PMC due to previous error (AE_NOT_EXIST) (20230628/psparse-529)
[ 3.717957] ACPI: \_SB_.PMI0: _PMC evaluation failed: AE_NOT_EXIST
On Dell systems several methods of acpi_power_meter access variables in
IPMI region [0], so wait until IPMI space handler is installed by
acpi_ipmi and also wait until SMI is selected to make the space handler
fully functional.
Since the dependency is inside BIOS's ASL code and it's not
discoverable, so use this fixup is a hack to workaround BIOS issue.
On Dell servers, many APCI methods of acpi_power_meter module evaluate
variables inside IPMI region, so the region handler needs to be
installed. In addition to that, the handler needs to be fully
functional, and that depends on SMI being selected.
So add a helper to let acpi_power_meter know when the handler is
installed and ready to be used.
Signed-off-by: Kai-Heng Feng <email address hidden>
Acked-by: Rafael J. Wysocki <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Guenter Roeck <email address hidden>
(cherry picked from commit b72cb1769b8419060651cf5b0c271f3872e88748 linux-next)
Signed-off-by: Kai-Heng Feng <email address hidden>
Acked-by: Aaron Ma <email address hidden>
Acked-by: Chris Chiu <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>
