kernel.git/arch/arm64/kernel/acpi.c, branch linux-4.19.y

acpi/arm64: ignore 5.1 FADTs that are reported as 5.0

2019-07-26T07:14:10Z

[ Upstream commit 2af22f3ec3ca452f1e79b967f634708ff01ced8a ] Some Qualcomm Snapdragon based laptops built to run Microsoft Windows are clearly ACPI 5.1 based, given that that is the first ACPI revision that supports ARM, and introduced the FADT 'arm_boot_flags' field, which has a non-zero field on those systems. So in these cases, infer from the ARM boot flags that the FADT must be 5.1 or later, and treat it as 5.1. Acked-by: Sudeep Holla Tested-by: Lee Jones Reviewed-by: Graeme Gregory Acked-by: Lorenzo Pieralisi Acked-by: Hanjun Guo Signed-off-by: Ard Biesheuvel Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin

arm64: acpi: fix alignment fault in accessing ACPI

2018-07-23T14:34:12Z

This is a fix against the issue that crash dump kernel may hang up during booting, which can happen on any ACPI-based system with "ACPI Reclaim Memory." (kernel messages after panic kicked off kdump) (snip...) Bye! (snip...) ACPI: Core revision 20170728 pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707 Internal error: Oops: 96000021 [#1] SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1 task: ffff000008d05180 task.stack: ffff000008cc0000 PC is at acpi_ns_lookup+0x25c/0x3c0 LR is at acpi_ds_load1_begin_op+0xa4/0x294 (snip...) Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000) Call trace: (snip...) [] acpi_ns_lookup+0x25c/0x3c0 [] acpi_ds_load1_begin_op+0xa4/0x294 [] acpi_ps_build_named_op+0xc4/0x198 [] acpi_ps_create_op+0x14c/0x270 [] acpi_ps_parse_loop+0x188/0x5c8 [] acpi_ps_parse_aml+0xb0/0x2b8 [] acpi_ns_one_complete_parse+0x144/0x184 [] acpi_ns_parse_table+0x48/0x68 [] acpi_ns_load_table+0x4c/0xdc [] acpi_tb_load_namespace+0xe4/0x264 [] acpi_load_tables+0x48/0xc0 [] acpi_early_init+0x9c/0xd0 [] start_kernel+0x3b4/0x43c Code: b9008fb9 2a000318 36380054 32190318 (b94002c0) ---[ end trace c46ed37f9651c58e ]--- Kernel panic - not syncing: Fatal exception Rebooting in 10 seconds.. (diagnosis) * This fault is a data abort, alignment fault (ESR=0x96000021) during reading out ACPI table. * Initial ACPI tables are normally stored in system ram and marked as "ACPI Reclaim memory" by the firmware. * After the commit f56ab9a5b73c ("efi/arm: Don't mark ACPI reclaim memory as MEMBLOCK_NOMAP"), those regions are differently handled as they are "memblock-reserved", without NOMAP bit. * So they are now excluded from device tree's "usable-memory-range" which kexec-tools determines based on a current view of /proc/iomem. * When crash dump kernel boots up, it tries to accesses ACPI tables by mapping them with ioremap(), not ioremap_cache(), in acpi_os_ioremap() since they are no longer part of mapped system ram. * Given that ACPI accessor/helper functions are compiled in without unaligned access support (ACPI_MISALIGNMENT_NOT_SUPPORTED), any unaligned access to ACPI tables can cause a fatal panic. With this patch, acpi_os_ioremap() always honors memory attribute information provided by the firmware (EFI) and retaining cacheability allows the kernel safe access to ACPI tables. Signed-off-by: AKASHI Takahiro Reviewed-by: James Morse Reviewed-by: Ard Biesheuvel Reported-by and Tested-by: Bhupesh Sharma Signed-off-by: Will Deacon

Merge tag 'acpi-part2-4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

2018-02-09T17:44:25Z

Pull more ACPI updates from Rafael Wysocki: "These are mostly fixes and cleanups, a few new quirks, a couple of updates related to the handling of ACPI tables and ACPICA copyrights refreshment. Specifics: - Update the ACPICA kernel code to upstream revision 20180105 including: * Assorted fixes (Jung-uk Kim) * Support for X32 ABI compilation (Anuj Mittal) * Update of ACPICA copyrights to 2018 (Bob Moore) - Prepare for future modifications to avoid executing the _STA control method too early (Hans de Goede) - Make the processor performance control library code ignore _PPC notifications if they cannot be handled and fix up the C1 idle state definition when it is used as a fallback state (Chen Yu, Yazen Ghannam) - Make it possible to use the SPCR table on x86 and to replace the original IORT table with a new one from initrd (Prarit Bhargava, Shunyong Yang) - Add battery-related quirks for Asus UX360UA and UX410UAK and add quirks for table parsing on Dell XPS 9570 and Precision M5530 (Kai Heng Feng) - Address static checker warnings in the CPPC code (Gustavo Silva) - Avoid printing a raw pointer to the kernel log in the smart battery driver (Greg Kroah-Hartman)" * tag 'acpi-part2-4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: sbshc: remove raw pointer from printk() message ACPI: SPCR: Make SPCR available to x86 ACPI / CPPC: Use 64-bit arithmetic instead of 32-bit ACPI / tables: Add IORT to injectable table list ACPI / bus: Parse tables as term_list for Dell XPS 9570 and Precision M5530 ACPICA: Update version to 20180105 ACPICA: All acpica: Update copyrights to 2018 ACPI / processor: Set default C1 idle state description ACPI / battery: Add quirk for Asus UX360UA and UX410UAK ACPI: processor_perflib: Do not send _PPC change notification if not ready ACPI / scan: Use acpi_bus_get_status() to initialize ACPI_TYPE_DEVICE devs ACPI / bus: Do not call _STA on battery devices with unmet dependencies PCI: acpiphp_ibm: prepare for acpi_get_object_info() no longer returning status ACPI: export acpi_bus_get_status_handle() ACPICA: Add a missing pair of parentheses ACPICA: Prefer ACPI_TO_POINTER() over ACPI_ADD_PTR() ACPICA: Avoid NULL pointer arithmetic ACPICA: Linux: add support for X32 ABI compilation ACPI / video: Use true for boolean value

ACPI: SPCR: Make SPCR available to x86

2018-02-07T10:39:58Z

SPCR is currently only enabled or ARM64 and x86 can use SPCR to setup an early console. General fixes include updating Documentation & Kconfig (for x86), updating comments, and changing parse_spcr() to acpi_parse_spcr(), and earlycon_init_is_deferred to earlycon_acpi_spcr_enable to be more descriptive. On x86, many systems have a valid SPCR table but the table version is not 2 so the table version check must be a warning. On ARM64 when the kernel parameter earlycon is used both the early console and console are enabled. On x86, only the earlycon should be enabled by by default. Modify acpi_parse_spcr() to allow options for initializing the early console and console separately. Signed-off-by: Prarit Bhargava Acked-by: Ingo Molnar Reviewed-by: Mark Salter Tested-by: Mark Salter Signed-off-by: Rafael J. Wysocki

arm64: acpi: Remove __init from acpi_psci_use_hvc() for use by SDEI

2018-01-14T18:49:49Z

SDEI inherits the 'use hvc' bit that is also used by PSCI. PSCI does all its initialisation early, SDEI does its late. Remove the __init annotation from acpi_psci_use_hvc(). Acked-by: Lorenzo Pieralisi Signed-off-by: James Morse Acked-by: Catalin Marinas Signed-off-by: Catalin Marinas

ACPI / boot: Correct address space of __acpi_map_table()

2017-07-24T20:47:56Z

Sparse complains about wrong address space used in __acpi_map_table() and in __acpi_unmap_table(). arch/x86/kernel/acpi/boot.c:127:29: warning: incorrect type in return expression (different address spaces) arch/x86/kernel/acpi/boot.c:127:29: expected char * arch/x86/kernel/acpi/boot.c:127:29: got void [noderef] * arch/x86/kernel/acpi/boot.c:135:23: warning: incorrect type in argument 1 (different address spaces) arch/x86/kernel/acpi/boot.c:135:23: expected void [noderef] *addr arch/x86/kernel/acpi/boot.c:135:23: got char *map Correct address space to be in align of type of returned and passed parameter. Reviewed-by: Hanjun Guo Signed-off-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki

efi/bgrt: Enable ACPI BGRT handling on arm64

2017-04-05T10:27:25Z

Now that the ACPI BGRT handling code has been made generic, we can enable it for arm64. Signed-off-by: Bhupesh Sharma [ Updated commit log to reflect that BGRT is only enabled for arm64, and added missing 'return' statement to the dummy acpi_parse_bgrt() function. ] Signed-off-by: Ard Biesheuvel Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170404160245.27812-8-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar

ACPI / osl: Remove acpi_get_table_with_size()/early_acpi_os_unmap_memory() users

2016-12-21T01:36:38Z

This patch removes the users of the deprectated APIs: acpi_get_table_with_size() early_acpi_os_unmap_memory() The following APIs should be used instead of: acpi_get_table() acpi_put_table() The deprecated APIs are invented to be a replacement of acpi_get_table() during the early stage so that the early mapped pointer will not be stored in ACPICA core and thus the late stage acpi_get_table() won't return a wrong pointer. The mapping size is returned just because it is required by early_acpi_os_unmap_memory() to unmap the pointer during early stage. But as the mapping size equals to the acpi_table_header.length (see acpi_tb_init_table_descriptor() and acpi_tb_validate_table()), when such a convenient result is returned, driver code will start to use it instead of accessing acpi_table_header to obtain the length. Thus this patch cleans up the drivers by replacing returned table size with acpi_table_header.length, and should be a no-op. Reported-by: Dan Williams Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

ARM64: ACPI: enable ACPI_SPCR_TABLE

2016-09-28T15:46:57Z

SBBR mentions SPCR as a mandatory ACPI table. So enable it for ARM64 Earlycon should be set up as early as possible. ACPI boot tables are mapped in arch/arm64/kernel/acpi.c:acpi_boot_table_init() that is called from setup_arch() and that's where we parse SPCR. So it has to be opted-in per-arch. When ACPI_SPCR_TABLE is defined initialization of DT earlycon is deferred until the DT/ACPI decision is done. Initialize DT earlycon if ACPI is disabled. Acked-by: Will Deacon Acked-by: Hanjun Guo Signed-off-by: Aleksey Makarov Tested-by: Kefeng Wang Tested-by: Christopher Covington Signed-off-by: Greg Kroah-Hartman

arm64: acpi: add acpi=on cmdline option to prefer ACPI boot over DT

2016-04-26T13:37:41Z

If both ACPI and DT platform descriptions are available, and the kernel was configured at build time to support both flavours, the default policy is to prefer DT over ACPI, and preferring ACPI over DT while still allowing DT as a fallback is not possible. Since some enterprise features (such as RAS) depend on ACPI, it may be desirable for, e.g., distro installers to prefer ACPI boot but fall back to DT rather than failing completely if no ACPI tables are available. So introduce the 'acpi=on' kernel command line parameter for arm64, which signifies that ACPI should be used if available, and DT should only be used as a fallback. Acked-by: Catalin Marinas Signed-off-by: Ard Biesheuvel Signed-off-by: Will Deacon