linux-stable.git/drivers/acpi, branch linux-5.17.y

ACPI: property: Release subnode properties with data nodes

2022-06-09T08:26:19+00:00

commit 3bd561e1572ee02a50cd1a5be339abf1a5b78d56 upstream.

struct acpi_device_properties describes one source of properties present
on either struct acpi_device or struct acpi_data_node. When properties are
parsed, both are populated but when released, only those properties that
are associated with the device node are freed.

Fix this by also releasing memory of the data node properties.

Fixes: 5f5e4890d57a ("ACPI / property: Allow multiple property compatible _DSD entries")
Cc: 4.20+  # 4.20+
Signed-off-by: Sakari Ailus 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI: CPPC: Assume no transition latency if no PCCT

2022-06-09T08:25:29+00:00

[ Upstream commit 6380b7b2b29da9d9c5ab2d4a265901cd93ba3696 ]

The transition_delay_us (struct cpufreq_policy) is currently defined
as:
  Preferred average time interval between consecutive invocations of
  the driver to set the frequency for this policy.  To be set by the
  scaling driver (0, which is the default, means no preference).
The transition_latency represents the amount of time necessary for a
CPU to change its frequency.

A PCCT table advertises mutliple values:
- pcc_nominal: Expected latency to process a command, in microseconds
- pcc_mpar: The maximum number of periodic requests that the subspace
  channel can support, reported in commands per minute. 0 indicates no
  limitation.
- pcc_mrtt: The minimum amount of time that OSPM must wait after the
  completion of a command before issuing the next command,
  in microseconds.
cppc_get_transition_latency() allows to get the max of them.

commit d4f3388afd48 ("cpufreq / CPPC: Set platform specific
transition_delay_us") allows to select transition_delay_us based on
the platform, and fallbacks to cppc_get_transition_latency()
otherwise.

If _CPC objects are not using PCC channels (no PPCT table), the
transition_delay_us is set to CPUFREQ_ETERNAL, leading to really long
periods between frequency updates (~4s).

If the desired_reg, where performance requests are written, is in
SystemMemory or SystemIo ACPI address space, there is no delay
in requests. So return 0 instead of CPUFREQ_ETERNAL, leading to
transition_delay_us being set to LATENCY_MULTIPLIER us (1000 us).

This patch also adds two macros to check the address spaces.

Signed-off-by: Pierre Gondois 
Reviewed-by: Sudeep Holla 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

ACPI: PM: Block ASUS B1400CEAE from suspend to idle by default

2022-06-09T08:25:26+00:00

[ Upstream commit d52848620de00cde4a3a5df908e231b8c8868250 ]

ASUS B1400CEAE fails to resume from suspend to idle by default.  This was
bisected back to commit df4f9bc4fb9c ("nvme-pci: add support for ACPI
StorageD3Enable property") but this is a red herring to the problem.

Before this commit the system wasn't getting into deepest sleep state.
Presumably this commit is allowing entry into deepest sleep state as
advertised by firmware, but there are some other problems related to
the wakeup.

As it is confirmed the system works properly with S3, set the default for
this system to S3.

Reported-by: Jian-Hong Pan 
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215742
Signed-off-by: Mario Limonciello 
Tested-by: Jian-Hong Pan 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

ACPI: sysfs: Fix BERT error region memory mapping

2022-05-30T07:27:19+00:00

commit 1bbc21785b7336619fb6a67f1fff5afdaf229acc upstream.

Currently the sysfs interface maps the BERT error region as "memory"
(through acpi_os_map_memory()) in order to copy the error records into
memory buffers through memory operations (eg memory_read_from_buffer()).

The OS system cannot detect whether the BERT error region is part of
system RAM or it is "device memory" (eg BMC memory) and therefore it
cannot detect which memory attributes the bus to memory support (and
corresponding kernel mapping, unless firmware provides the required
information).

The acpi_os_map_memory() arch backend implementation determines the
mapping attributes. On arm64, if the BERT error region is not present in
the EFI memory map, the error region is mapped as device-nGnRnE; this
triggers alignment faults since memcpy unaligned accesses are not
allowed in device-nGnRnE regions.

The ACPI sysfs code cannot therefore map by default the BERT error
region with memory semantics but should use a safer default.

Change the sysfs code to map the BERT error region as MMIO (through
acpi_os_map_iomem()) and use the memcpy_fromio() interface to read the
error region into the kernel buffer.

Link: https://lore.kernel.org/linux-arm-kernel/31ffe8fc-f5ee-2858-26c5-0fd8bdd68702@arm.com
Link: https://lore.kernel.org/linux-acpi/CAJZ5v0g+OVbhuUUDrLUCfX_mVqY_e8ubgLTU98=jfjTeb4t+Pw@mail.gmail.com
Signed-off-by: Lorenzo Pieralisi 
Tested-by: Veronika Kabatova 
Tested-by: Aristeu Rozanski 
Acked-by: Ard Biesheuvel 
Signed-off-by: Rafael J. Wysocki 
Cc: dann frazier 
Signed-off-by: Greg Kroah-Hartman

ACPI: processor: idle: Avoid falling back to C3 type C-states

2022-05-09T07:16:30+00:00

commit fc45e55ebc58dbf622cb89ddbf797589c7a5510b upstream.

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+  # 5.16+
Signed-off-by: Ville Syrjälä 
Tested-by: Woody Suwalski 
[ rjw: Subject and changelog adjustments ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

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

2022-05-09T07:16:29+00:00

commit 20e582e16af24b074e583f9551fad557882a3c9d upstream.

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ä 
Cc: 5.16+  # 5.16+
Tested-by: Woody Suwalski 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI: processor idle: Check for architectural support for LPI

2022-04-20T07:36:06+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

Revert "ACPI: processor: idle: Only flush cache on entering C3"

2022-04-13T17:27:40+00:00

commit dfbba2518aac4204203b0697a894d3b2f80134d3 upstream.

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 
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki 
Cc: Ketsui 
Signed-off-by: Greg Kroah-Hartman

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

2022-04-08T11:58:58+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-08T11:58:38+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