linux-stable.git/include/linux/acpi.h, branch v4.19.239

ACPI: tables: x86: Reserve memory occupied by ACPI tables

2021-05-07T08:49:25+00:00

commit 1a1c130ab7575498eed5bcf7220037ae09cd1f8a upstream.

The following problem has been reported by George Kennedy:

 Since commit 7fef431be9c9 ("mm/page_alloc: place pages to tail
 in __free_pages_core()") the following use after free occurs
 intermittently when ACPI tables are accessed.

 BUG: KASAN: use-after-free in ibft_init+0x134/0xc49
 Read of size 4 at addr ffff8880be453004 by task swapper/0/1
 CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc1-7a7fd0d #1
 Call Trace:
  dump_stack+0xf6/0x158
  print_address_description.constprop.9+0x41/0x60
  kasan_report.cold.14+0x7b/0xd4
  __asan_report_load_n_noabort+0xf/0x20
  ibft_init+0x134/0xc49
  do_one_initcall+0xc4/0x3e0
  kernel_init_freeable+0x5af/0x66b
  kernel_init+0x16/0x1d0
  ret_from_fork+0x22/0x30

 ACPI tables mapped via kmap() do not have their mapped pages
 reserved and the pages can be "stolen" by the buddy allocator.

Apparently, on the affected system, the ACPI table in question is
not located in "reserved" memory, like ACPI NVS or ACPI Data, that
will not be used by the buddy allocator, so the memory occupied by
that table has to be explicitly reserved to prevent the buddy
allocator from using it.

In order to address this problem, rearrange the initialization of the
ACPI tables on x86 to locate the initial tables earlier and reserve
the memory occupied by them.

The other architectures using ACPI should not be affected by this
change.

Link: https://lore.kernel.org/linux-acpi/1614802160-29362-1-git-send-email-george.kennedy@oracle.com/
Reported-by: George Kennedy 
Tested-by: George Kennedy 
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Mike Rapoport 
Cc: 5.10+  # 5.10+
Signed-off-by: Greg Kroah-Hartman

ACPI: scan: add stub acpi_create_platform_device() for !CONFIG_ACPI

2021-01-19T17:22:36+00:00

[ Upstream commit ee61cfd955a64a58ed35cbcfc54068fcbd486945 ]

It adds a stub acpi_create_platform_device() for !CONFIG_ACPI build, so
that caller doesn't have to deal with !CONFIG_ACPI build issue.

Reported-by: kernel test robot 
Signed-off-by: Shawn Guo 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

ACPI: PM: Introduce "poweroff" callbacks for ACPI PM domain and LPSS

2020-01-27T13:51:00+00:00

[ Upstream commit c95b7595f85c688d5c569ddbbd6ab6a4bdae2f36 ]

In general, it is not correct to call pm_generic_suspend(),
pm_generic_suspend_late() and pm_generic_suspend_noirq() during the
hibernation's "poweroff" transition, because device drivers may
provide special callbacks to be invoked then and the wrappers in
question cause system suspend callbacks to be run.  Unfortunately,
that happens in the ACPI PM domain and ACPI LPSS.

To address this potential issue, introduce "poweroff" callbacks
for the ACPI PM and LPSS that will use pm_generic_poweroff(),
pm_generic_poweroff_late() and pm_generic_poweroff_noirq() as
appropriate.

Fixes: 05087360fd7a (ACPI / PM: Take SMART_SUSPEND driver flag into account)
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Mika Westerberg 
Reviewed-by: Hans de Goede 
Signed-off-by: Sasha Levin

ACPI: PM: Simplify and fix PM domain hibernation callbacks

2020-01-27T13:50:59+00:00

[ Upstream commit 3cd7957e85e67120bb9f6bfb75d81dcc19af282b ]

First, after a previous change causing all runtime-suspended devices
in the ACPI PM domain (and ACPI LPSS devices) to be resumed before
creating a snapshot image of memory during hibernation, it is not
necessary to worry about the case in which them might be left in
runtime-suspend any more, so get rid of the code related to that from
ACPI PM domain and ACPI LPSS hibernation callbacks.

Second, it is not correct to use pm_generic_resume_early() and
acpi_subsys_resume_noirq() in hibernation "restore" callbacks (which
currently happens in the ACPI PM domain and ACPI LPSS), so introduce
proper _restore_late and _restore_noirq callbacks for the ACPI PM
domain and ACPI LPSS.

Fixes: 05087360fd7a (ACPI / PM: Take SMART_SUSPEND driver flag into account)
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Mika Westerberg 
Reviewed-by: Hans de Goede 
Signed-off-by: Sasha Levin

ACPI: fix acpi_find_child_device() invocation in acpi_preset_companion()

2019-12-13T07:51:47+00:00

[ Upstream commit f8c6d1402b89f22a3647705d63cbd171aa19a77e ]

acpi_find_child_device() accepts boolean not pointer as last argument.

Signed-off-by: Alexey Dobriyan 
[ rjw: Subject ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

ACPI/PPTT: Add support for ACPI 6.3 thread flag

2019-10-17T20:45:34+00:00

Commit bbd1b70639f785a970d998f35155c713f975e3ac upstream.

ACPI 6.3 adds a flag to the CPU node to indicate whether
the given PE is a thread. Add a function to return that
information for a given linux logical CPU.

Signed-off-by: Jeremy Linton 
Reviewed-by: Sudeep Holla 
Reviewed-by: Robert Richter 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Will Deacon 
[jpg: backport for 4.19, replace acpi_pptt_warn_missing()]
Signed-off-by: John Garry 
Signed-off-by: Sasha Levin

ACPI: fix false-positive -Wuninitialized warning

2019-08-06T17:06:50+00:00

[ Upstream commit dfd6f9ad36368b8dbd5f5a2b2f0a4705ae69a323 ]

clang gets confused by an uninitialized variable in what looks
to it like a never executed code path:

arch/x86/kernel/acpi/boot.c:618:13: error: variable 'polarity' is uninitialized when used here [-Werror,-Wuninitialized]
        polarity = polarity ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
                   ^~~~~~~~
arch/x86/kernel/acpi/boot.c:606:32: note: initialize the variable 'polarity' to silence this warning
        int rc, irq, trigger, polarity;
                                      ^
                                       = 0
arch/x86/kernel/acpi/boot.c:617:12: error: variable 'trigger' is uninitialized when used here [-Werror,-Wuninitialized]
        trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
                  ^~~~~~~
arch/x86/kernel/acpi/boot.c:606:22: note: initialize the variable 'trigger' to silence this warning
        int rc, irq, trigger, polarity;
                            ^
                             = 0

This is unfortunately a design decision in clang and won't be fixed.

Changing the acpi_get_override_irq() macro to an inline function
reliably avoids the issue.

Signed-off-by: Arnd Bergmann 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Nathan Chancellor 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

ACPI: property: Make the ACPI graph API private

2018-07-23T10:44:52+00:00

The fwnode graph API is preferred over the ACPI graph API. Therefore
make the ACPI graph API private, and use it as a back-end for the
fwnode graph API only.

Unused functionality is removed while the functionality actually used
remains the same.

Signed-off-by: Sakari Ailus 
Signed-off-by: Rafael J. Wysocki

ACPI: Convert ACPI reference args to generic fwnode reference args

2018-07-23T10:44:52+00:00

Convert all users of struct acpi_reference_args to more generic
fwnode_reference_args. This will

 1) avoid an ACPI specific references to device nodes with integer
    arguments as well as

 2) allow making references to nodes other than device nodes in ACPI.

As a by-product, convert the fwnode interger arguments to u64. The
arguments were 64-bit integers on ACPI but the fwnode arguments were
just 32-bit.

Signed-off-by: Sakari Ailus 
Signed-off-by: Rafael J. Wysocki

acpi: Add helper for deactivating memory region

2018-06-25T13:30:12+00:00

Sometimes memory resource may be overlapping with
SystemMemory Operation Region by design, for example if the
memory region is used as a mailbox for communication with a
firmware in the system. One occasion of such mailboxes is
USB Type-C Connector System Software Interface (UCSI).

With regions like that, it is important that the driver is
able to map the memory with the requirements it has. For
example, the driver should be allowed to map the memory as
non-cached memory. However, if the operation region has been
accessed before the driver has mapped the memory, the memory
has been marked as write-back by the time the driver is
loaded. That means the driver will fail to map the memory
if it expects non-cached memory.

To work around the problem, introducing helper that the
drivers can use to temporarily deactivate (unmap)
SystemMemory Operation Regions that overlap with their
IO memory.

Fixes: 8243edf44152 ("usb: typec: ucsi: Add ACPI driver")
Cc: stable@vger.kernel.org
Reviewed-by: Rafael J. Wysocki 
Signed-off-by: Heikki Krogerus 
Signed-off-by: Greg Kroah-Hartman