linux-stable.git/drivers/acpi/processor_idle.c, branch v5.19.2 Linux kernel stable tree ACPI: processor/idle: Annotate more functions to live in cpuidle section 2022-08-17T13:14:07+00:00 Guilherme G. Piccoli gpiccoli@igalia.com 2022-06-07T22:24:58+00:00 6f556550328ea44b574eb0c50184eb9fe38b24f4 [ Upstream commit 409dfdcaffb266acfc1f33529a26b1443c9332d4 ] Commit 6727ad9e206c ("nmi_backtrace: generate one-line reports for idle cpus") introduced a new text section called cpuidle; with that, we have a mechanism to add idling functions in such section and skip them from nmi_backtrace output, since they're useless and potentially flooding for such report. Happens that inlining might cause some real idle functions to end-up outside of such section; this is currently the case of ACPI processor_idle driver; the functions acpi_idle_enter_* do inline acpi_idle_do_entry(), hence they stay out of the cpuidle section. Fix that by marking such functions to also live in the cpuidle section. Fixes: 6727ad9e206c ("nmi_backtrace: generate one-line reports for idle cpus") Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 409dfdcaffb266acfc1f33529a26b1443c9332d4 ]

Commit 6727ad9e206c ("nmi_backtrace: generate one-line reports for idle cpus")
introduced a new text section called cpuidle; with that, we have a mechanism
to add idling functions in such section and skip them from nmi_backtrace
output, since they're useless and potentially flooding for such report.

Happens that inlining might cause some real idle functions to end-up
outside of such section; this is currently the case of ACPI processor_idle
driver; the functions acpi_idle_enter_* do inline acpi_idle_do_entry(),
hence they stay out of the cpuidle section.
Fix that by marking such functions to also live in the cpuidle section.

Fixes: 6727ad9e206c ("nmi_backtrace: generate one-line reports for idle cpus")
Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Merge branches 'acpi-glue', 'acpi-osl', 'acpi-processor' and 'acpi-cppc' 2022-05-30T16:04:57+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2022-05-30T16:04:57+00:00 15f4bb9aac620f7ca1e50c859731e7d990f807ed Merge general ACPI cleanups and processor support updates for 5.19-rc1: - Rearrange find_child_checks() to simplify code (Rafael Wysocki). - Use memremap() to map the UCSI mailbox that is always in main memory and drop acpi_release_memory() that has no more users (Heikki Krogerus, Dan Carpenter). - Make max_cstate/nocst/bm_check_disable processor module parameters visible in sysfs (Yajun Deng). - Fix typo in the CPPC driver (Julia Lawall). * acpi-glue: ACPI: glue: Rearrange find_child_checks() * acpi-osl: usb: typec: ucsi: acpi: fix a NULL vs IS_ERR() check in probe ACPI: OSL: Remove the helper for deactivating memory region usb: typec: ucsi: acpi: Map the mailbox with memremap() * acpi-processor: ACPI: processor: idle: Expose max_cstate/nocst/bm_check_disable read-only in sysfs * acpi-cppc: ACPI: CPPC: fix typo in comment 
Merge general ACPI cleanups and processor support updates for 5.19-rc1:

 - Rearrange find_child_checks() to simplify code (Rafael Wysocki).

 - Use memremap() to map the UCSI mailbox that is always in main memory
   and drop acpi_release_memory() that has no more users (Heikki
   Krogerus, Dan Carpenter).

 - Make max_cstate/nocst/bm_check_disable processor module parameters
   visible in sysfs (Yajun Deng).

 - Fix typo in the CPPC driver (Julia Lawall).

* acpi-glue:
  ACPI: glue: Rearrange find_child_checks()

* acpi-osl:
  usb: typec: ucsi: acpi: fix a NULL vs IS_ERR() check in probe
  ACPI: OSL: Remove the helper for deactivating memory region
  usb: typec: ucsi: acpi: Map the mailbox with memremap()

* acpi-processor:
  ACPI: processor: idle: Expose max_cstate/nocst/bm_check_disable read-only in sysfs

* acpi-cppc:
  ACPI: CPPC: fix typo in comment
Merge branch 'v5.18-rc5' 2022-05-11T14:27:06+00:00 Peter Zijlstra peterz@infradead.org 2022-05-11T14:27:06+00:00 47319846a9e2ab1c4d22108e891818d003615bd8 Obtain the new INTEL_FAM6 stuff required. Signed-off-by: Peter Zijlstra <peterz@infradead.org> 
Obtain the new INTEL_FAM6 stuff required.

Signed-off-by: Peter Zijlstra <peterz@infradead.org>
ACPI: processor: idle: Expose max_cstate/nocst/bm_check_disable read-only in sysfs 2022-05-06T18:45:40+00:00 Yajun Deng yajun.deng@linux.dev 2022-04-28T09:54:13+00:00 27263b3428f5b2b73be97adf3d679125b6065271 This will allow super users to verify the module parameters in question when changed via kernel command line. The parameters "nocst/bm_check_disable" are only used for enable/disable, so change them from integer to bool. Signed-off-by: Yajun Deng <yajun.deng@linux.dev> [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
This will allow super users to verify the module parameters in question
when changed via kernel command line.

The parameters "nocst/bm_check_disable" are only used for enable/disable,
so change them from integer to bool.

Signed-off-by: Yajun Deng <yajun.deng@linux.dev>
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Revert "ACPI: processor: idle: fix lockup regression on 32-bit ThinkPad T40" 2022-04-21T17:58:14+00:00 Ville Syrjälä ville.syrjala@linux.intel.com 2022-04-20T13:44:17+00:00 20e582e16af24b074e583f9551fad557882a3c9d This reverts commit bfe55a1f7fd6bfede16078bf04c6250fbca11588. This was presumably misdiagnosed as an inability to use C3 at all when I suspect the real problem is just misconfiguration of C3 vs. ARB_DIS. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: 5.16+ <stable@vger.kernel.org> # 5.16+ Tested-by: Woody Suwalski <wsuwalski@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
This reverts commit bfe55a1f7fd6bfede16078bf04c6250fbca11588.

This was presumably misdiagnosed as an inability to use C3 at
all when I suspect the real problem is just misconfiguration of
C3 vs. ARB_DIS.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: 5.16+ <stable@vger.kernel.org> # 5.16+
Tested-by: Woody Suwalski <wsuwalski@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI: processor: idle: Avoid falling back to C3 type C-states 2022-04-21T17:55:41+00:00 Ville Syrjälä ville.syrjala@linux.intel.com 2022-04-21T13:36:34+00:00 fc45e55ebc58dbf622cb89ddbf797589c7a5510b The "safe state" index is used by acpi_idle_enter_bm() to avoid entering a C-state that may require bus mastering to be disabled on entry in the cases when this is not going to happen. For this reason, it should not be set to point to C3 type of C-states, because they may require bus mastering to be disabled on entry in principle. This was broken by commit d6b88ce2eb9d ("ACPI: processor idle: Allow playing dead in C3 state") which inadvertently allowed the "safe state" index to point to C3 type of C-states. This results in a machine that won't boot past the point when it first enters C3. Restore the correct behaviour (either demote to C1/C2, or use C3 but also set ARB_DIS=1). I hit this on a Fujitsu Siemens Lifebook S6010 (P3) machine. Fixes: d6b88ce2eb9d ("ACPI: processor idle: Allow playing dead in C3 state") Cc: 5.16+ <stable@vger.kernel.org> # 5.16+ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Woody Suwalski <wsuwalski@gmail.com> [ rjw: Subject and changelog adjustments ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
The "safe state" index is used by acpi_idle_enter_bm() to avoid
entering a C-state that may require bus mastering to be disabled
on entry in the cases when this is not going to happen.  For this
reason, it should not be set to point to C3 type of C-states, because
they may require bus mastering to be disabled on entry in principle.

This was broken by commit d6b88ce2eb9d ("ACPI: processor idle: Allow
playing dead in C3 state") which inadvertently allowed the "safe
state" index to point to C3 type of C-states.

This results in a machine that won't boot past the point when it first
enters C3. Restore the correct behaviour (either demote to C1/C2, or
use C3 but also set ARB_DIS=1).

I hit this on a Fujitsu Siemens Lifebook S6010 (P3) machine.

Fixes: d6b88ce2eb9d ("ACPI: processor idle: Allow playing dead in C3 state")
Cc: 5.16+ <stable@vger.kernel.org> # 5.16+
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Woody Suwalski <wsuwalski@gmail.com>
[ rjw: Subject and changelog adjustments ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI: Add perf low power callback 2022-04-05T08:24:38+00:00 Stephane Eranian eranian@google.com 2022-03-22T22:15:12+00:00 2a606a18cd672a16343d146a126721b34cc6adbd Add an optional callback needed by some PMU features, e.g., AMD BRS, to give a chance to the perf_events code to change its state before a CPU goes to low power and after it comes back. The callback is void when the PERF_NEEDS_LOPWR_CB flag is not set. This flag must be set in arch specific perf_event.h header whenever needed. When not set, there is no impact on the ACPI code. Signed-off-by: Stephane Eranian <eranian@google.com> [peterz: build fix] Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20220322221517.2510440-9-eranian@google.com 
Add an optional callback needed by some PMU features, e.g., AMD
BRS, to give a chance to the perf_events code to change its state before
a CPU goes to low power and after it comes back.

The callback is void when the PERF_NEEDS_LOPWR_CB flag is not set.
This flag must be set in arch specific perf_event.h header whenever needed.
When not set, there is no impact on the ACPI code.

Signed-off-by: Stephane Eranian <eranian@google.com>
[peterz: build fix]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20220322221517.2510440-9-eranian@google.com
Revert "ACPI: processor: idle: Only flush cache on entering C3" 2022-04-04T18:51:15+00:00 Akihiko Odaki akihiko.odaki@gmail.com 2022-04-03T06:23:22+00:00 dfbba2518aac4204203b0697a894d3b2f80134d3 Revert commit 87ebbb8c612b ("ACPI: processor: idle: Only flush cache on entering C3") that broke the assumptions of the acpi_idle_play_dead() callers. Namely, the CPU cache must always be flushed in acpi_idle_play_dead(), regardless of the target C-state that is going to be requested, because this is likely to be part of a CPU offline procedure or preparation for entering a system-wide sleep state and the lack of synchronization between the CPU cache and RAM may lead to problems going forward, for example when the CPU is brought back online. In particular, it breaks resume from suspend-to-RAM on Lenovo ThinkPad C13 which fails occasionally until the problematic commit is reverted. Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
Revert commit 87ebbb8c612b ("ACPI: processor: idle: Only flush cache
on entering C3") that broke the assumptions of the acpi_idle_play_dead()
callers.

Namely, the CPU cache must always be flushed in acpi_idle_play_dead(),
regardless of the target C-state that is going to be requested, because
this is likely to be part of a CPU offline procedure or preparation for
entering a system-wide sleep state and the lack of synchronization
between the CPU cache and RAM may lead to problems going forward, for
example when the CPU is brought back online.

In particular, it breaks resume from suspend-to-RAM on Lenovo ThinkPad
C13 which fails occasionally until the problematic commit is reverted.

Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI: processor idle: Check for architectural support for LPI 2022-03-03T19:20:06+00:00 Mario Limonciello mario.limonciello@amd.com 2022-02-25T19:06:46+00:00 eb087f305919ee8169ad65665610313e74260463 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 <sudeep.holla@arm.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
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 <sudeep.holla@arm.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI: processor: idle: fix lockup regression on 32-bit ThinkPad T40 2022-02-16T17:17:16+00:00 Woody Suwalski wsuwalski@gmail.com 2022-02-09T21:05:09+00:00 bfe55a1f7fd6bfede16078bf04c6250fbca11588 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 <richard.gong@amd.com> 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 <wsuwalski@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Cc: 5.16+ <stable@vger.kernel.org> # 5.16+ [ rjw: New subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
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 <richard.gong@amd.com>
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 <wsuwalski@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Cc: 5.16+ <stable@vger.kernel.org> # 5.16+
[ rjw: New subject ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>