[PATCH v2 0/8][Regression][Unstable][Cosmic][SRU Bionic] Fix kernel crashdump on arm64

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH v2 0/8][Regression][Unstable][Cosmic][SRU Bionic] Fix kernel crashdump on arm64

dann frazier-4
BugLink: https://bugs.launchpad.net/bugs/1786878

1 new [Config] switch activated, all other changes are clean cherry-picks
from upstream.

v2:
  Add upstream fixes to resolve Kconfig dependency loop.

AKASHI Takahiro (3):
  drivers: acpi: add dependency of EFI for arm64
  efi/arm: map UEFI memory map even w/o runtime services enabled
  arm64: acpi: fix alignment fault in accessing ACPI

Ard Biesheuvel (1):
  efi/arm: preserve early mapping of UEFI memory map longer for BGRT

Arnd Bergmann (2):
  arm64: fix ACPI dependencies
  ACPI: fix menuconfig presentation of ACPI submenu

James Morse (1):
  arm64: export memblock_reserve()d regions via /proc/iomem

dann frazier (1):
  UBUNTU: [Config] CONFIG_ARCH_SUPPORTS_ACPI=y

 arch/arm64/Kconfig                        |  1 +
 arch/arm64/include/asm/acpi.h             | 23 +++++++++-----
 arch/arm64/kernel/acpi.c                  | 11 ++-----
 arch/arm64/kernel/setup.c                 | 38 +++++++++++++++++++++++
 arch/ia64/Kconfig                         |  1 +
 arch/x86/Kconfig                          |  1 +
 debian.master/config/config.common.ubuntu |  1 +
 drivers/acpi/Kconfig                      |  8 +++--
 drivers/firmware/efi/arm-init.c           |  1 -
 drivers/firmware/efi/arm-runtime.c        | 18 ++++++-----
 10 files changed, 76 insertions(+), 27 deletions(-)

--
2.18.0


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[PATCH v2 1/8][Cosmic][SRU Bionic] arm64: export memblock_reserve()d regions via /proc/iomem

dann frazier-4
From: James Morse <[hidden email]>

BugLink: https://bugs.launchpad.net/bugs/1786878

There has been some confusion around what is necessary to prevent kexec
overwriting important memory regions. memblock: reserve, or nomap?
Only memblock nomap regions are reported via /proc/iomem, kexec's
user-space doesn't know about memblock_reserve()d regions.

Until commit f56ab9a5b73ca ("efi/arm: Don't mark ACPI reclaim memory
as MEMBLOCK_NOMAP") the ACPI tables were nomap, now they are reserved
and thus possible for kexec to overwrite with the new kernel or initrd.
But this was always broken, as the UEFI memory map is also reserved
and not marked as nomap.

Exporting both nomap and reserved memblock types is a nuisance as
they live in different memblock structures which we can't walk at
the same time.

Take a second walk over memblock.reserved and add new 'reserved'
subnodes for the memblock_reserved() regions that aren't already
described by the existing code. (e.g. Kernel Code)

We use reserve_region_with_split() to find the gaps in existing named
regions. This handles the gap between 'kernel code' and 'kernel data'
which is memblock_reserve()d, but already partially described by
request_standard_resources(). e.g.:
| 80000000-dfffffff : System RAM
|   80080000-80ffffff : Kernel code
|   81000000-8158ffff : reserved
|   81590000-8237efff : Kernel data
|   a0000000-dfffffff : Crash kernel
| e00f0000-f949ffff : System RAM

reserve_region_with_split needs kzalloc() which isn't available when
request_standard_resources() is called, use an initcall.

Reported-by: Bhupesh Sharma <[hidden email]>
Reported-by: Tyler Baicar <[hidden email]>
Suggested-by: Akashi Takahiro <[hidden email]>
Signed-off-by: James Morse <[hidden email]>
Fixes: d28f6df1305a ("arm64/kexec: Add core kexec support")
Reviewed-by: Ard Biesheuvel <[hidden email]>
CC: Mark Rutland <[hidden email]>
Signed-off-by: Will Deacon <[hidden email]>
(cherry picked from commit 50d7ba36b916d0fd4687149ec143bf49c326523f)
Signed-off-by: dann frazier <[hidden email]>
---
 arch/arm64/kernel/setup.c | 38 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 30ad2f085d1f0..5b4fac434c841 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -241,6 +241,44 @@ static void __init request_standard_resources(void)
  }
 }
 
+static int __init reserve_memblock_reserved_regions(void)
+{
+ phys_addr_t start, end, roundup_end = 0;
+ struct resource *mem, *res;
+ u64 i;
+
+ for_each_reserved_mem_region(i, &start, &end) {
+ if (end <= roundup_end)
+ continue; /* done already */
+
+ start = __pfn_to_phys(PFN_DOWN(start));
+ end = __pfn_to_phys(PFN_UP(end)) - 1;
+ roundup_end = end;
+
+ res = kzalloc(sizeof(*res), GFP_ATOMIC);
+ if (WARN_ON(!res))
+ return -ENOMEM;
+ res->start = start;
+ res->end = end;
+ res->name  = "reserved";
+ res->flags = IORESOURCE_MEM;
+
+ mem = request_resource_conflict(&iomem_resource, res);
+ /*
+ * We expected memblock_reserve() regions to conflict with
+ * memory created by request_standard_resources().
+ */
+ if (WARN_ON_ONCE(!mem))
+ continue;
+ kfree(res);
+
+ reserve_region_with_split(mem, start, end, "reserved");
+ }
+
+ return 0;
+}
+arch_initcall(reserve_memblock_reserved_regions);
+
 u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
 
 void __init setup_arch(char **cmdline_p)
--
2.18.0


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[PATCH v2 2/8][Cosmic][SRU Bionic] drivers: acpi: add dependency of EFI for arm64

dann frazier-4
In reply to this post by dann frazier-4
From: AKASHI Takahiro <[hidden email]>

BugLink: https://bugs.launchpad.net/bugs/1786878

As Ard suggested, CONFIG_ACPI && !CONFIG_EFI doesn't make sense on arm64,
while CONFIG_ACPI and CONFIG_CPU_BIG_ENDIAN doesn't make sense either.

As CONFIG_EFI already has a dependency of !CONFIG_CPU_BIG_ENDIAN, it is
good enough to add a dependency of CONFIG_EFI to avoid any useless
combination of configuration.

This bug, reported by Will, will be revealed when my patch series,
"arm64: kexec,kdump: fix boot failures on acpi-only system," is applied
and the kernel is built under allmodconfig.

Signed-off-by: AKASHI Takahiro <[hidden email]>
Suggested-by: Ard Biesheuvel <[hidden email]>
Signed-off-by: Will Deacon <[hidden email]>
(cherry picked from commit 5bcd44083a082f314032969cd6db1eb8275ac77a)
Signed-off-by: dann frazier <[hidden email]>
---
 drivers/acpi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index b533eeb6139d2..15ab1daaa8081 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -6,7 +6,7 @@
 menuconfig ACPI
  bool "ACPI (Advanced Configuration and Power Interface) Support"
  depends on !IA64_HP_SIM
- depends on IA64 || X86 || ARM64
+ depends on IA64 || X86 || (ARM64 && EFI)
  depends on PCI
  select PNP
  default y if (IA64 || X86)
--
2.18.0


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[PATCH v2 3/8][Cosmic][SRU Bionic] efi/arm: preserve early mapping of UEFI memory map longer for BGRT

dann frazier-4
In reply to this post by dann frazier-4
From: Ard Biesheuvel <[hidden email]>

BugLink: https://bugs.launchpad.net/bugs/1786878

The BGRT code validates the contents of the table against the UEFI
memory map, and so it expects it to be mapped when the code runs.

On ARM, this is currently not the case, since we tear down the early
mapping after efi_init() completes, and only create the permanent
mapping in arm_enable_runtime_services(), which executes as an early
initcall, but still leaves a window where the UEFI memory map is not
mapped.

So move the call to efi_memmap_unmap() from efi_init() to
arm_enable_runtime_services().

Signed-off-by: Ard Biesheuvel <[hidden email]>
[will: fold in EFI_MEMMAP attribute check from Ard]
Signed-off-by: Will Deacon <[hidden email]>
(cherry picked from commit 3ea86495aef2f6de26b7cb1599ba350dd6a0c521)
Signed-off-by: dann frazier <[hidden email]>
---
 drivers/firmware/efi/arm-init.c    | 1 -
 drivers/firmware/efi/arm-runtime.c | 4 +++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 80d1a885def5c..a7c522eac640f 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -259,7 +259,6 @@ void __init efi_init(void)
 
  reserve_regions();
  efi_esrt_init();
- efi_memmap_unmap();
 
  memblock_reserve(params.mmap & PAGE_MASK,
  PAGE_ALIGN(params.mmap_size +
diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
index 5889cbea60b84..4712445c32130 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -110,11 +110,13 @@ static int __init arm_enable_runtime_services(void)
 {
  u64 mapsize;
 
- if (!efi_enabled(EFI_BOOT)) {
+ if (!efi_enabled(EFI_BOOT) || !efi_enabled(EFI_MEMMAP)) {
  pr_info("EFI services will not be available.\n");
  return 0;
  }
 
+ efi_memmap_unmap();
+
  if (efi_runtime_disabled()) {
  pr_info("EFI runtime services will be disabled.\n");
  return 0;
--
2.18.0


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[PATCH v2 4/8][Cosmic][SRU Bionic] efi/arm: map UEFI memory map even w/o runtime services enabled

dann frazier-4
In reply to this post by dann frazier-4
From: AKASHI Takahiro <[hidden email]>

BugLink: https://bugs.launchpad.net/bugs/1786878

Under the current implementation, UEFI memory map will be mapped and made
available in virtual mappings only if runtime services are enabled.
But in a later patch, we want to use UEFI memory map in acpi_os_ioremap()
to create mappings of ACPI tables using memory attributes described in
UEFI memory map.
See the following commit:
    arm64: acpi: fix alignment fault in accessing ACPI tables

So, as a first step, arm_enter_runtime_services() is modified, alongside
Ard's patch[1], so that UEFI memory map will not be freed even if
efi=noruntime.

[1] https://marc.info/?l=linux-efi&m=152930773507524&w=2

Signed-off-by: AKASHI Takahiro <[hidden email]>
Reviewed-by: Ard Biesheuvel <[hidden email]>
Signed-off-by: Will Deacon <[hidden email]>
(cherry picked from commit 20d12cf990618845e76d3f24daaebd15d65a5e46)
Signed-off-by: dann frazier <[hidden email]>
---
 drivers/firmware/efi/arm-runtime.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
index 4712445c32130..922cfb813109a 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -117,6 +117,13 @@ static int __init arm_enable_runtime_services(void)
 
  efi_memmap_unmap();
 
+ mapsize = efi.memmap.desc_size * efi.memmap.nr_map;
+
+ if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) {
+ pr_err("Failed to remap EFI memory map\n");
+ return 0;
+ }
+
  if (efi_runtime_disabled()) {
  pr_info("EFI runtime services will be disabled.\n");
  return 0;
@@ -129,13 +136,6 @@ static int __init arm_enable_runtime_services(void)
 
  pr_info("Remapping and enabling EFI services.\n");
 
- mapsize = efi.memmap.desc_size * efi.memmap.nr_map;
-
- if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) {
- pr_err("Failed to remap EFI memory map\n");
- return -ENOMEM;
- }
-
  if (!efi_virtmap_init()) {
  pr_err("UEFI virtual mapping missing or invalid -- runtime services will not be available\n");
  return -ENOMEM;
--
2.18.0


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[PATCH v2 5/8][Cosmic][SRU Bionic] arm64: acpi: fix alignment fault in accessing ACPI

dann frazier-4
In reply to this post by dann frazier-4
From: AKASHI Takahiro <[hidden email]>

BugLink: https://bugs.launchpad.net/bugs/1786878

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...)
        [<ffff0000084a6764>] acpi_ns_lookup+0x25c/0x3c0
        [<ffff00000849b4f8>] acpi_ds_load1_begin_op+0xa4/0x294
        [<ffff0000084ad4ac>] acpi_ps_build_named_op+0xc4/0x198
        [<ffff0000084ad6cc>] acpi_ps_create_op+0x14c/0x270
        [<ffff0000084acfa8>] acpi_ps_parse_loop+0x188/0x5c8
        [<ffff0000084ae048>] acpi_ps_parse_aml+0xb0/0x2b8
        [<ffff0000084a8e10>] acpi_ns_one_complete_parse+0x144/0x184
        [<ffff0000084a8e98>] acpi_ns_parse_table+0x48/0x68
        [<ffff0000084a82cc>] acpi_ns_load_table+0x4c/0xdc
        [<ffff0000084b32f8>] acpi_tb_load_namespace+0xe4/0x264
        [<ffff000008baf9b4>] acpi_load_tables+0x48/0xc0
        [<ffff000008badc20>] acpi_early_init+0x9c/0xd0
        [<ffff000008b70d50>] 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 <[hidden email]>
Reviewed-by: James Morse <[hidden email]>
Reviewed-by: Ard Biesheuvel <[hidden email]>
Reported-by and Tested-by: Bhupesh Sharma <[hidden email]>
Signed-off-by: Will Deacon <[hidden email]>
(cherry picked from commit 09ffcb0d718a0b100f0bed029b830987ecf53fab)
Signed-off-by: dann frazier <[hidden email]>
---
 arch/arm64/include/asm/acpi.h | 23 ++++++++++++++++-------
 arch/arm64/kernel/acpi.c      | 11 +++--------
 2 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 0db62a4cbce2d..68bc18cb2b854 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -12,10 +12,12 @@
 #ifndef _ASM_ACPI_H
 #define _ASM_ACPI_H
 
+#include <linux/efi.h>
 #include <linux/memblock.h>
 #include <linux/psci.h>
 
 #include <asm/cputype.h>
+#include <asm/io.h>
 #include <asm/smp_plat.h>
 #include <asm/tlbflush.h>
 
@@ -29,18 +31,22 @@
 
 /* Basic configuration for ACPI */
 #ifdef CONFIG_ACPI
+pgprot_t __acpi_get_mem_attribute(phys_addr_t addr);
+
 /* ACPI table mapping after acpi_permanent_mmap is set */
 static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
     acpi_size size)
 {
+ /* For normal memory we already have a cacheable mapping. */
+ if (memblock_is_map_memory(phys))
+ return (void __iomem *)__phys_to_virt(phys);
+
  /*
- * EFI's reserve_regions() call adds memory with the WB attribute
- * to memblock via early_init_dt_add_memory_arch().
+ * We should still honor the memory's attribute here because
+ * crash dump kernel possibly excludes some ACPI (reclaim)
+ * regions from memblock list.
  */
- if (!memblock_is_memory(phys))
- return ioremap(phys, size);
-
- return ioremap_cache(phys, size);
+ return __ioremap(phys, size, __acpi_get_mem_attribute(phys));
 }
 #define acpi_os_ioremap acpi_os_ioremap
 
@@ -129,7 +135,10 @@ static inline const char *acpi_get_enable_method(int cpu)
  * for compatibility.
  */
 #define acpi_disable_cmcff 1
-pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
+static inline pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
+{
+ return __acpi_get_mem_attribute(addr);
+}
 #endif /* CONFIG_ACPI_APEI */
 
 #ifdef CONFIG_ACPI_NUMA
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 7b09487ff8fb6..ed46dc188b225 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -18,6 +18,7 @@
 #include <linux/acpi.h>
 #include <linux/bootmem.h>
 #include <linux/cpumask.h>
+#include <linux/efi.h>
 #include <linux/efi-bgrt.h>
 #include <linux/init.h>
 #include <linux/irq.h>
@@ -29,13 +30,9 @@
 
 #include <asm/cputype.h>
 #include <asm/cpu_ops.h>
+#include <asm/pgtable.h>
 #include <asm/smp_plat.h>
 
-#ifdef CONFIG_ACPI_APEI
-# include <linux/efi.h>
-# include <asm/pgtable.h>
-#endif
-
 int acpi_noirq = 1; /* skip ACPI IRQ initialization */
 int acpi_disabled = 1;
 EXPORT_SYMBOL(acpi_disabled);
@@ -239,8 +236,7 @@ void __init acpi_boot_table_init(void)
  }
 }
 
-#ifdef CONFIG_ACPI_APEI
-pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
+pgprot_t __acpi_get_mem_attribute(phys_addr_t addr)
 {
  /*
  * According to "Table 8 Map: EFI memory types to AArch64 memory
@@ -261,4 +257,3 @@ pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
  return __pgprot(PROT_NORMAL_NC);
  return __pgprot(PROT_DEVICE_nGnRnE);
 }
-#endif
--
2.18.0


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[PATCH v2 6/8][Cosmic][SRU Bionic] UBUNTU: [Config] CONFIG_ARCH_SUPPORTS_ACPI=y

dann frazier-4
In reply to this post by dann frazier-4
BugLink: https://bugs.launchpad.net/bugs/1786878

Signed-off-by: dann frazier <[hidden email]>
---
 debian.master/config/config.common.ubuntu | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian.master/config/config.common.ubuntu b/debian.master/config/config.common.ubuntu
index 342ebccb5bf60..630e2c714c54a 100644
--- a/debian.master/config/config.common.ubuntu
+++ b/debian.master/config/config.common.ubuntu
@@ -478,6 +478,7 @@ CONFIG_ARCH_SPRD=y
 # CONFIG_ARCH_STI is not set
 # CONFIG_ARCH_STM32 is not set
 CONFIG_ARCH_STRATIX10=y
+CONFIG_ARCH_SUPPORTS_ACPI=y
 CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
 CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y
 CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
--
2.18.0


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[PATCH v2 7/8][Cosmic][SRU Bionic] arm64: fix ACPI dependencies

dann frazier-4
In reply to this post by dann frazier-4
From: Arnd Bergmann <[hidden email]>

BugLink: https://bugs.launchpad.net/bugs/1786878

Kconfig reports a warning on x86 builds after the ARM64 dependency
was added.

drivers/acpi/Kconfig:6:error: recursive dependency detected!
drivers/acpi/Kconfig:6:       symbol ACPI depends on EFI

This rephrases the dependency to keep the ARM64 details out of the
shared Kconfig file, so Kconfig no longer gets confused by it.

For consistency, all three architectures that support ACPI now
select ARCH_SUPPORTS_ACPI in exactly the configuration in which
they allow it. We still need the 'default x86', as each one
wants a different default: default-y on x86, default-n on arm64,
and always-y on ia64.

Fixes: 5bcd44083a08 ("drivers: acpi: add dependency of EFI for arm64")
Reviewed-by: Rafael J. Wysocki <[hidden email]>
Acked-by: Will Deacon <[hidden email]>
Signed-off-by: Arnd Bergmann <[hidden email]>
Signed-off-by: Will Deacon <[hidden email]>
(cherry picked from commit 2c870e61132c082a03769d2ac0a2849ba33c10e3)
Signed-off-by: dann frazier <[hidden email]>
---
 arch/arm64/Kconfig   | 1 +
 arch/ia64/Kconfig    | 1 +
 arch/x86/Kconfig     | 1 +
 drivers/acpi/Kconfig | 8 +++++---
 4 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 2379f0a878ef1..6e4a945d2ff9d 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1251,6 +1251,7 @@ config EFI
  bool "UEFI runtime support"
  depends on OF && !CPU_BIG_ENDIAN
  depends on KERNEL_MODE_NEON
+ select ARCH_SUPPORTS_ACPI
  select LIBFDT
  select UCS2_STRING
  select EFI_PARAMS_FROM_FDT
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index bbe12a038d210..7c3e4e8a1e6ce 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -16,6 +16,7 @@ config IA64
  select ARCH_MIGHT_HAVE_PC_SERIO
  select PCI if (!IA64_HP_SIM)
  select ACPI if (!IA64_HP_SIM)
+ select ARCH_SUPPORTS_ACPI if (!IA64_HP_SIM)
  select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI
  select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
  select HAVE_UNSTABLE_SCHED_CLOCK
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 474ac10b43ec1..6dcb96b008403 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -71,6 +71,7 @@ config X86
  select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
  select ARCH_MIGHT_HAVE_PC_PARPORT
  select ARCH_MIGHT_HAVE_PC_SERIO
+ select ARCH_SUPPORTS_ACPI
  select ARCH_SUPPORTS_ATOMIC_RMW
  select ARCH_SUPPORTS_NUMA_BALANCING if X86_64
  select ARCH_USE_BUILTIN_BSWAP
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 15ab1daaa8081..4a46344bf0e3f 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -5,11 +5,10 @@
 
 menuconfig ACPI
  bool "ACPI (Advanced Configuration and Power Interface) Support"
- depends on !IA64_HP_SIM
- depends on IA64 || X86 || (ARM64 && EFI)
+ depends on ARCH_SUPPORTS_ACPI
  depends on PCI
  select PNP
- default y if (IA64 || X86)
+ default y if X86
  help
   Advanced Configuration and Power Interface (ACPI) support for
   Linux requires an ACPI-compliant platform (hardware/firmware),
@@ -41,6 +40,9 @@ menuconfig ACPI
   <http://www.acpi.info>
   <http://www.uefi.org/acpi/specs>
 
+config ARCH_SUPPORTS_ACPI
+ bool
+
 if ACPI
 
 config ACPI_LEGACY_TABLES_LOOKUP
--
2.18.0


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[PATCH v2 8/8][Cosmic][SRU Bionic] ACPI: fix menuconfig presentation of ACPI submenu

dann frazier-4
In reply to this post by dann frazier-4
From: Arnd Bergmann <[hidden email]>

BugLink: https://bugs.launchpad.net/bugs/1786878

My fix for a recursive Kconfig dependency caused another issue where the
ACPI specific options end up in the top-level menu in 'menuconfig'. This
was an unintended side-effect of having a silent option between
'menuconfig ACPI' and 'if ACPI'.

Moving the ARCH_SUPPORTS_ACPI symbol ahead of the ACPI menu solves that
problem and restores the previous presentation.

Reported-by: Ard Biesheuvel <[hidden email]>
Fixes: 2c870e61132c (arm64: fix ACPI dependencies)
Signed-off-by: Arnd Bergmann <[hidden email]>
Signed-off-by: Rafael J. Wysocki <[hidden email]>
(cherry picked from commit f5d707ede37a962bc3cb9b3f8531a870dae29e46)
Signed-off-by: dann frazier <[hidden email]>
---
 drivers/acpi/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 4a46344bf0e3f..dd1eea90f67f1 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -3,6 +3,9 @@
 # ACPI Configuration
 #
 
+config ARCH_SUPPORTS_ACPI
+ bool
+
 menuconfig ACPI
  bool "ACPI (Advanced Configuration and Power Interface) Support"
  depends on ARCH_SUPPORTS_ACPI
@@ -40,9 +43,6 @@ menuconfig ACPI
   <http://www.acpi.info>
   <http://www.uefi.org/acpi/specs>
 
-config ARCH_SUPPORTS_ACPI
- bool
-
 if ACPI
 
 config ACPI_LEGACY_TABLES_LOOKUP
--
2.18.0


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

ACK: [PATCH v2 0/8][Regression][Unstable][Cosmic][SRU Bionic] Fix kernel crashdump on arm64

Stefan Bader-2
In reply to this post by dann frazier-4
On 28.08.2018 22:47, dann frazier wrote:

> BugLink: https://bugs.launchpad.net/bugs/1786878
>
> 1 new [Config] switch activated, all other changes are clean cherry-picks
> from upstream.
>
> v2:
>   Add upstream fixes to resolve Kconfig dependency loop.
>
> AKASHI Takahiro (3):
>   drivers: acpi: add dependency of EFI for arm64
>   efi/arm: map UEFI memory map even w/o runtime services enabled
>   arm64: acpi: fix alignment fault in accessing ACPI
>
> Ard Biesheuvel (1):
>   efi/arm: preserve early mapping of UEFI memory map longer for BGRT
>
> Arnd Bergmann (2):
>   arm64: fix ACPI dependencies
>   ACPI: fix menuconfig presentation of ACPI submenu
>
> James Morse (1):
>   arm64: export memblock_reserve()d regions via /proc/iomem
>
> dann frazier (1):
>   UBUNTU: [Config] CONFIG_ARCH_SUPPORTS_ACPI=y
>
>  arch/arm64/Kconfig                        |  1 +
>  arch/arm64/include/asm/acpi.h             | 23 +++++++++-----
>  arch/arm64/kernel/acpi.c                  | 11 ++-----
>  arch/arm64/kernel/setup.c                 | 38 +++++++++++++++++++++++
>  arch/ia64/Kconfig                         |  1 +
>  arch/x86/Kconfig                          |  1 +
>  debian.master/config/config.common.ubuntu |  1 +
>  drivers/acpi/Kconfig                      |  8 +++--
>  drivers/firmware/efi/arm-init.c           |  1 -
>  drivers/firmware/efi/arm-runtime.c        | 18 ++++++-----
>  10 files changed, 76 insertions(+), 27 deletions(-)
>
Acked-by: Stefan Bader <[hidden email]>


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

ACK: [PATCH v2 0/8][Regression][Unstable][Cosmic][SRU Bionic] Fix kernel crashdump on arm64

Colin Ian King-2
In reply to this post by dann frazier-4
On 28/08/18 21:47, dann frazier wrote:

> BugLink: https://bugs.launchpad.net/bugs/1786878
>
> 1 new [Config] switch activated, all other changes are clean cherry-picks
> from upstream.
>
> v2:
>   Add upstream fixes to resolve Kconfig dependency loop.
>
> AKASHI Takahiro (3):
>   drivers: acpi: add dependency of EFI for arm64
>   efi/arm: map UEFI memory map even w/o runtime services enabled
>   arm64: acpi: fix alignment fault in accessing ACPI
>
> Ard Biesheuvel (1):
>   efi/arm: preserve early mapping of UEFI memory map longer for BGRT
>
> Arnd Bergmann (2):
>   arm64: fix ACPI dependencies
>   ACPI: fix menuconfig presentation of ACPI submenu
>
> James Morse (1):
>   arm64: export memblock_reserve()d regions via /proc/iomem
>
> dann frazier (1):
>   UBUNTU: [Config] CONFIG_ARCH_SUPPORTS_ACPI=y
>
>  arch/arm64/Kconfig                        |  1 +
>  arch/arm64/include/asm/acpi.h             | 23 +++++++++-----
>  arch/arm64/kernel/acpi.c                  | 11 ++-----
>  arch/arm64/kernel/setup.c                 | 38 +++++++++++++++++++++++
>  arch/ia64/Kconfig                         |  1 +
>  arch/x86/Kconfig                          |  1 +
>  debian.master/config/config.common.ubuntu |  1 +
>  drivers/acpi/Kconfig                      |  8 +++--
>  drivers/firmware/efi/arm-init.c           |  1 -
>  drivers/firmware/efi/arm-runtime.c        | 18 ++++++-----
>  10 files changed, 76 insertions(+), 27 deletions(-)
>

All seem very reasonable fixes to me.

Acked-by: Colin Ian King <[hidden email]>

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

APPLIED[C/Unstable]: [PATCH v2 0/8][Regression][Unstable][Cosmic][SRU Bionic] Fix kernel crashdump on arm64

Seth Forshee
In reply to this post by dann frazier-4
On Tue, Aug 28, 2018 at 02:47:31PM -0600, dann frazier wrote:
> BugLink: https://bugs.launchpad.net/bugs/1786878
>
> 1 new [Config] switch activated, all other changes are clean cherry-picks
> from upstream.
>
> v2:
>   Add upstream fixes to resolve Kconfig dependency loop.

Applied to cosmic/master-next and unstable/master, thanks!

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

APPLIED: [PATCH v2 0/8][Regression][Unstable][Cosmic][SRU Bionic] Fix kernel crashdump on arm64

Kleber Souza
In reply to this post by dann frazier-4
On 08/28/18 22:47, dann frazier wrote:

> BugLink: https://bugs.launchpad.net/bugs/1786878
>
> 1 new [Config] switch activated, all other changes are clean cherry-picks
> from upstream.
>
> v2:
>   Add upstream fixes to resolve Kconfig dependency loop.
>
> AKASHI Takahiro (3):
>   drivers: acpi: add dependency of EFI for arm64
>   efi/arm: map UEFI memory map even w/o runtime services enabled
>   arm64: acpi: fix alignment fault in accessing ACPI
>
> Ard Biesheuvel (1):
>   efi/arm: preserve early mapping of UEFI memory map longer for BGRT
>
> Arnd Bergmann (2):
>   arm64: fix ACPI dependencies
>   ACPI: fix menuconfig presentation of ACPI submenu
>
> James Morse (1):
>   arm64: export memblock_reserve()d regions via /proc/iomem
>
> dann frazier (1):
>   UBUNTU: [Config] CONFIG_ARCH_SUPPORTS_ACPI=y
>
>  arch/arm64/Kconfig                        |  1 +
>  arch/arm64/include/asm/acpi.h             | 23 +++++++++-----
>  arch/arm64/kernel/acpi.c                  | 11 ++-----
>  arch/arm64/kernel/setup.c                 | 38 +++++++++++++++++++++++
>  arch/ia64/Kconfig                         |  1 +
>  arch/x86/Kconfig                          |  1 +
>  debian.master/config/config.common.ubuntu |  1 +
>  drivers/acpi/Kconfig                      |  8 +++--
>  drivers/firmware/efi/arm-init.c           |  1 -
>  drivers/firmware/efi/arm-runtime.c        | 18 ++++++-----
>  10 files changed, 76 insertions(+), 27 deletions(-)
>

Applied to bionic/master-next branch, with some fuzzing adjustments on
patches 6/8 and 7/8.

Thanks,
Kleber

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team