BMC/Intel-BMC/linux.git/drivers/acpi, branch dev-5.15-intel

ACPI: processor: idle: fix lockup regression on 32-bit ThinkPad T40

2022-04-20T07:34:04+00:00

commit bfe55a1f7fd6bfede16078bf04c6250fbca11588 upstream. Add and ACPI idle power level limit for 32-bit ThinkPad T40. There is a regression on T40 introduced by commit d6b88ce2, starting with kernel 5.16: commit d6b88ce2eb9d2698eb24451eb92c0a1649b17bb1 Author: Richard Gong Date: Wed Sep 22 08:31:16 2021 -0500 ACPI: processor idle: Allow playing dead in C3 state The above patch is trying to enter C3 state during init, what is causing a T40 system freeze. I have not found a similar issue on any other of my 32-bit machines. The fix is to add another exception to the processor_power_dmi_table[] list. As a result the dmesg shows as expected: [2.155398] ACPI: IBM ThinkPad T40 detected - limiting to C2 max_cstate. Override with "processor.max_cstate=9" [2.155404] ACPI: processor limited to max C-state 2 The fix is trivial and affects only vintage T40 systems. Fixes: d6b88ce2eb9d ("CPI: processor idle: Allow playing dead in C3 state") Signed-off-by: Woody Suwalski Reviewed-by: Hans de Goede Cc: 5.16+ # 5.16+ [ rjw: New subject ] Signed-off-by: Rafael J. Wysocki Cc: "Limonciello, Mario" Signed-off-by: Greg Kroah-Hartman

ACPI: processor idle: Allow playing dead in C3 state

2022-04-20T07:34:04+00:00

commit d6b88ce2eb9d2698eb24451eb92c0a1649b17bb1 upstream. When some cores are disabled on AMD platforms, the system will no longer be able to enter suspend-to-idle s0ix. Update to allow playing dead in C3 state so that the CPUs can enter the deepest state on AMD platforms. BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1708 Suggested-by: Mario Limonciello Signed-off-by: Richard Gong [ rjw: Fixed coding style ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI: processor idle: Check for architectural support for LPI

2022-04-20T07:34:04+00:00

commit eb087f305919ee8169ad65665610313e74260463 upstream. When `osc_pc_lpi_support_confirmed` is set through `_OSC` and `_LPI` is populated then the cpuidle driver assumes that LPI is fully functional. However currently the kernel only provides architectural support for LPI on ARM. This leads to high power consumption on X86 platforms that otherwise try to enable LPI. So probe whether or not LPI support is implemented before enabling LPI in the kernel. This is done by overloading `acpi_processor_ffh_lpi_probe` to check whether it returns `-EOPNOTSUPP`. It also means that all future implementations of `acpi_processor_ffh_lpi_probe` will need to follow these semantics as well. Reviewed-by: Sudeep Holla Signed-off-by: Mario Limonciello Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI: CPPC: Avoid out of bounds access when parsing _CPC data

2022-04-08T12:24:12+00:00

commit 40d8abf364bcab23bc715a9221a3c8623956257b upstream. If the NumEntries field in the _CPC return package is less than 2, do not attempt to access the "Revision" element of that package, because it may not be present then. Fixes: 337aadff8e45 ("ACPI: Introduce CPU performance controls using CPPC") BugLink: https://lore.kernel.org/lkml/20220322143534.GC32582@xsang-OptiPlex-9020/ Reported-by: kernel test robot Signed-off-by: Rafael J. Wysocki Reviewed-by: Huang Rui Signed-off-by: Greg Kroah-Hartman

ACPI/APEI: Limit printable size of BERT table data

2022-04-08T12:23:56+00:00

[ Upstream commit 3f8dec116210ca649163574ed5f8df1e3b837d07 ] Platforms with large BERT table data can trigger soft lockup errors while attempting to print the entire BERT table data to the console at boot: watchdog: BUG: soft lockup - CPU#160 stuck for 23s! [swapper/0:1] Observed on Ampere Altra systems with a single BERT record of ~250KB. The original bert driver appears to have assumed relatively small table data. Since it is impractical to reassemble large table data from interwoven console messages, and the table data is available in /sys/firmware/acpi/tables/data/BERT limit the size for tables printed to the console to 1024 (for no reason other than it seemed like a good place to kick off the discussion, would appreciate feedback from existing users in terms of what size would maintain their current usage model). Alternatively, we could make printing a CONFIG option, use the bert_disable boot arg (or something similar), or use a debug log level. However, all those solutions require extra steps or change the existing behavior for small table data. Limiting the size preserves existing behavior on existing platforms with small table data, and eliminates the soft lockups for platforms with large table data, while still making it available. Signed-off-by: Darren Hart Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPICA: Avoid walking the ACPI Namespace if it is not there

2022-04-08T12:23:56+00:00

[ Upstream commit 0c9992315e738e7d6e927ef36839a466b080dba6 ] ACPICA commit b1c3656ef4950098e530be68d4b589584f06cddc Prevent acpi_ns_walk_namespace() from crashing when called with start_node equal to ACPI_ROOT_OBJECT if the Namespace has not been instantiated yet and acpi_gbl_root_node is NULL. For instance, this can happen if the kernel is run with "acpi=off" in the command line. Link: https://github.com/acpica/acpica/commit/b1c3656ef4950098e530be68d4b589584f06cddc Link: https://lore.kernel.org/linux-acpi/CAJZ5v0hJWW_vZ3wwajE7xT38aWjY7cZyvqMJpXHzUL98-SiCVQ@mail.gmail.com/ Reported-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: APEI: fix return value of __setup handlers

2022-04-08T12:23:09+00:00

[ Upstream commit f3303ff649dbf7dcdc6a6e1a922235b12b3028f4 ] __setup() handlers should return 1 to indicate that the boot option has been handled. Returning 0 causes a boot option to be listed in the Unknown kernel command line parameters and also added to init's arg list (if no '=' sign) or environment list (if of the form 'a=b'). Unknown kernel command line parameters "erst_disable bert_disable hest_disable BOOT_IMAGE=/boot/bzImage-517rc6", will be passed to user space. Run /sbin/init as init process with arguments: /sbin/init erst_disable bert_disable hest_disable with environment: HOME=/ TERM=linux BOOT_IMAGE=/boot/bzImage-517rc6 Fixes: a3e2acc5e37b ("ACPI / APEI: Add Boot Error Record Table (BERT) support") Fixes: a08f82d08053 ("ACPI, APEI, Error Record Serialization Table (ERST) support") Fixes: 9dc966641677 ("ACPI, APEI, HEST table parsing") Signed-off-by: Randy Dunlap Reported-by: Igor Zhbanov Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru Reviewed-by: "Huang, Ying" Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: properties: Consistently return -ENOENT if there are no more references

2022-04-08T12:22:58+00:00

commit babc92da5928f81af951663fc436997352e02d3a upstream. __acpi_node_get_property_reference() is documented to return -ENOENT if the caller requests a property reference at an index that does not exist, not -EINVAL which it actually does. Fix this by returning -ENOENT consistenly, independently of whether the property value is a plain reference or a package. Fixes: c343bc2ce2c6 ("ACPI: properties: Align return codes of __acpi_node_get_property_reference()") Cc: 4.14+ # 4.14+ Signed-off-by: Sakari Ailus Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

Revert "ACPI: Pass the same capabilities to the _OSC regardless of the query flag"

2022-04-08T12:22:58+00:00

commit 2ca8e6285250c07a2e5a22ecbfd59b5a4ef73484 upstream. Revert commit 159d8c274fd9 ("ACPI: Pass the same capabilities to the _OSC regardless of the query flag") which caused legitimate usage scenarios (when the platform firmware does not want the OS to control certain platform features controlled by the system bus scope _OSC) to break and was misguided by some misleading language in the _OSC definition in the ACPI specification (in particular, Section 6.2.11.1.3 "Sequence of _OSC Calls" that contradicts other perts of the _OSC definition). Link: https://lore.kernel.org/linux-acpi/CAJZ5v0iStA0JmO0H3z+VgQsVuQONVjKPpw0F5HKfiq=Gb6B5yw@mail.gmail.com Reported-by: Mario Limonciello Signed-off-by: Rafael J. Wysocki Tested-by: Mario Limonciello Acked-by: Huang Rui Reviewed-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman

ACPI: video: Force backlight native for Clevo NL5xRU and NL5xNU

2022-03-28T07:58:45+00:00

commit c844d22fe0c0b37dc809adbdde6ceb6462c43acf upstream. Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a working native and video interface. However the default detection mechanism first registers the video interface before unregistering it again and switching to the native interface during boot. This results in a dangling SBIOS request for backlight change for some reason, causing the backlight to switch to ~2% once per boot on the first power cord connect or disconnect event. Setting the native interface explicitly circumvents this buggy behaviour by avoiding the unregistering process. Signed-off-by: Werner Sembach Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman