Linaro-acpi August 2015

linaro-acpi@lists.linaro.org

24 participants
24 discussions

leg-kernel tag leg-20150821.0 released

by Graeme Gregory

The leg-kernel release has been made and tagged as leg-20150821.0 This is based on mainline kernel v4.2-rc7 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: http://git.linaro.org/leg/acpi/leg-kernel.git/commit/f54108bb7b07c9ce7100d4… Topic Branches :- http://git.linaro.org/leg/acpi/acpi.git - acpi-topic-arm64-apei - acpi-topic-juno-fvp - acpi-topic-nodevmem - acpi-topic-sbsa-watchdog - acpi-topic-seattle - acpi-topic-spcr - acpi-topic-bad-madt - topic-gic-self-probe http://git.linaro.org/people/graeme.gregory/linux.git - topic-capsule http://git.linaro.org/people/leif.lindholm/linux.git - arm64-pcihost-generic Mainline Based -------------- Repository: http://git.linaro.org/leg/acpi/acpi.git Branch: leg-kernel Tag: leg-mainline-20150820.0

8 years, 8 months

[PATCH] acpi, apei, arm64: APEI initial support for aarch64.

by fu.wei＠linaro.org

From: Tomasz Nowicki <tomasz.nowicki(a)linaro.org> This commit provides APEI arch-specific bits for aarch64 Changelog: Fu Wei: Move arch_apei_flush_tlb_one() to arch/arm64/include/asm/apci.h. Delete arch/arm64/kernel/apei.c. Add "#ifdef CONFIG_ACPI_APEI" for "acpi_disable_cmcff". Signed-off-by: Tomasz Nowicki <tomasz.nowicki(a)linaro.org> Signed-off-by: Fu Wei <fu.wei(a)linaro.org> --- arch/arm64/Kconfig | 1 + arch/arm64/include/asm/acpi.h | 11 +++++++++++ arch/arm64/kernel/acpi.c | 4 ++++ 3 files changed, 16 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 318175f..6144c9d 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -3,6 +3,7 @@ config ARM64 select ACPI_CCA_REQUIRED if ACPI select ACPI_GENERIC_GSI if ACPI select ACPI_REDUCED_HARDWARE_ONLY if ACPI + select HAVE_ACPI_APEI if ACPI select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE select ARCH_HAS_ELF_RANDOMIZE select ARCH_HAS_GCOV_PROFILE_ALL diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h index a17b623..ced6e25 100644 --- a/arch/arm64/include/asm/acpi.h +++ b/arch/arm64/include/asm/acpi.h @@ -22,6 +22,7 @@ #ifdef CONFIG_ACPI_APEI #include <linux/efi.h> #include <asm/pgtable.h> +#include <asm/tlbflush.h> #endif /* Macros for consistency checks of the GICC subtable of MADT */ @@ -52,6 +53,9 @@ typedef u64 phys_cpuid_t; extern int acpi_disabled; extern int acpi_noirq; extern int acpi_pci_disabled; +#ifdef CONFIG_ACPI_APEI +extern int acpi_disable_cmcff; +#endif static inline void disable_acpi(void) { @@ -89,6 +93,13 @@ static inline bool acpi_has_cpu_in_madt(void) static inline void arch_fix_phys_package_id(int num, u32 slot) { } void __init acpi_init_cpus(void); +#ifdef CONFIG_ACPI_APEI +static inline void arch_apei_flush_tlb_one(unsigned long addr) +{ + flush_tlb_kernel_range(addr, addr + PAGE_SIZE); +} +#endif + #else static inline void acpi_init_cpus(void) { } #endif /* CONFIG_ACPI */ diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c index 19de753..bd1be9a 100644 --- a/arch/arm64/kernel/acpi.c +++ b/arch/arm64/kernel/acpi.c @@ -36,6 +36,10 @@ EXPORT_SYMBOL(acpi_disabled); int acpi_pci_disabled = 1; /* skip ACPI PCI scan and IRQ initialization */ EXPORT_SYMBOL(acpi_pci_disabled); +#ifdef CONFIG_ACPI_APEI +int acpi_disable_cmcff; +#endif + static bool param_acpi_off __initdata; static bool param_acpi_force __initdata; -- 1.9.1

8 years, 8 months

Mustang branch boot issue

by Itaru Kitayama

Hi, I have been trying to boot the Mustang branch with acpi=force, but it stalls during the process I need to powercycle every time I enter that state. Checking setup_arch(), acpi_boot_table_init() seems to be ok, but it can not continue booting if disable_acpi() is not called before the block below: if (acpi_disabled) { unflatten_device_tree(); psci_dt_init(); } else { psci_acpi_init(); } Instead, calling disable_acpi() right after the block above ends up stalling. psci_acpi_init() does nothing on Mustang as it does not support the interface. Has anyone has an idea as to what's blocking the acpi=force boot process? Itaru

8 years, 8 months

[PATCH 0/5] ACPI: Provide better MADT subtable sanity checks

by Al Stone

Currently, the BAD_MADT_ENTRY macro is used to do a very simple sanity check on the various subtables that are defined for the MADT. The check compares the size of the subtable data structure as defined by ACPICA to the length entry in the subtable. If they are not the same, the assumption is that the subtable is incorrect. Over time, the ACPI spec has allowed for MADT subtables where this can never be true (the local SAPIC subtable, for example). Or, more recently, the spec has accumulated some minor flaws where there are three possible sizes for a subtable, all of which are valid, but only for specific versions of the spec (the GICC subtable). In both cases, BAD_MADT_ENTRY reports these subtables as bad when they are not. In order to retain some sanity check on the MADT subtables, we now have to special case these subtables. Of necessity, these special cases have ended up in arch-dependent code (arm64) or an arch has simply decided to forgo the check (ia64). This patch set replaces the BAD_MADT_ENTRY macro with a function called bad_madt_entry(). This function uses a data set of details about the subtables to provide more sanity checking than before: -- is the subtable legal for the version given in the FADT? -- is the subtable legal for the revision of the MADT in use? -- is the subtable of the proper length (including checking on the one variable length subtable that is currently ignored), given the FADT version and the MADT revision? Further, this patch set adds in the call to bad_madt_entry() from the acpi_table_parse_madt() function, allowing it to be used consistently by all architectures, for all subtables, and removing the need for each of the subtable traversal callback functions to use BAD_MADT_ENTRY. In theory, as the ACPI specification changes, we would only have to add additional information to the data set describing the MADT subtables in order to continue providing sanity checks, even when new subtables are added. These patches have been tested on an APM Mustang (arm64) and are known to work there. They have also been cross-compiled for x86 and ia64 with no known failures. Al Stone (5): ACPI: add in a bad_madt_entry() function to eventually replace the macro ACPI / ARM64: remove usage of BAD_MADT_ENTRY/BAD_MADT_GICC_ENTRY ACPI / IA64: remove usage of BAD_MADT_ENTRY ACPI / X86: remove usage of BAD_MADT_ENTRY ACPI: remove definition of BAD_MADT_ENTRY macro arch/arm64/include/asm/acpi.h | 8 -- arch/arm64/kernel/smp.c | 2 - arch/ia64/kernel/acpi.c | 20 ---- arch/x86/kernel/acpi/boot.c | 27 ----- drivers/acpi/tables.c | 241 ++++++++++++++++++++++++++++++++++++++++++ drivers/irqchip/irq-gic.c | 6 -- include/linux/acpi.h | 4 - 7 files changed, 241 insertions(+), 67 deletions(-) -- 2.4.3

8 years, 8 months

[PATCH v4 00/10] ACPI GIC Self-probing, GICv2m and GICv3 support

by Hanjun Guo

When ACPI core patches were merged into mainline, there were two TODOs for ACPI based GIC init, one is the Self-probing for GIC, the other one is to support stacked irq domain, also the feature of GICv2m and GICv3 is missing in that patch set. For ACPI Self-probing for GIC, thanks to the GIC version which is introduced in ACPI 6.0, we can match the GIC version and GIC driver, based on that, we introduce the self-probe infrastructure similar as IRQCHIP_DECLARE(), please see patch 1~3. The stacked domain thing is more complicated, Marc introduced a patchset to slove this problem (great thanks!) - Making the generic ACPI GSI layer irqdomain aware, which is avaiable at: git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/gsi-irq-domain-v2 so we reworked the GICv2m and GICv3 support on top of it, and combined them as a single patch set for review. Note: this patchset has no ITS support for GICv3/4, it will be implmented in the IORT patchset, which had a draft version but needs to rework it on top of Marc's Per-device MSI domain & platform MSI patchset. Tested on GICv2 based FVP base model and AMD Seattle platform, both wired interrupt and MSI (with some PCI patches) work fine. Patches are on top of Marc's branch irq/gsi-irq-domain-v2, and available at: git://git.linaro.org/leg/acpi/acpi.git gsi-irqdomain Comments are warmly welcomed. >From v3: - Rework GICv3 patches on top of Marc's tree - Add gicV2m support Hanjun Guo (5): irqchip / GIC: Add GIC version support in ACPI MADT ACPI / irqchip: Add self-probe infrastructure to initialize IRQ controller irqchip / GIC / ACPI: Use IRQCHIP_ACPI_DECLARE to simplify GICv2 init code irqchip / GICv3: remove the useless comparision of device node in xlate irqchip / GICv3 / ACPI: Add GICR support via GICC structures Suravee Suthikulpanit (3): ACPI: GIC: Add ACPI helper functions to query irq-domain tokens for for GIC MSI and ITS PCI: ACPI: Bind GIC MSI frame to PCI host bridge irqchip / gicv2m: Introducing gicv2m_acpi_init() Tomasz Nowicki (2): irqchip / GICv3: Refactor gic_of_init() for GICv3 driver irqchip / GICv3: Add ACPI support for GICv3+ initialization arch/arm64/Kconfig | 1 + arch/arm64/include/asm/irq.h | 13 -- arch/arm64/kernel/acpi.c | 25 -- drivers/acpi/Makefile | 1 + drivers/acpi/acpi_gic.c | 234 +++++++++++++++++++ drivers/irqchip/Kconfig | 3 + drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-gic-acpi.c | 175 ++++++++++++++ drivers/irqchip/irq-gic-v2m.c | 111 +++++++-- drivers/irqchip/irq-gic-v3.c | 438 +++++++++++++++++++++++++++++++---- drivers/irqchip/irq-gic.c | 6 +- drivers/pci/pci-acpi.c | 18 ++ drivers/pci/probe.c | 3 + include/acpi/acpi_gic.h | 23 ++ include/asm-generic/vmlinux.lds.h | 13 ++ include/linux/acpi.h | 17 ++ include/linux/acpi_irq.h | 4 +- include/linux/irqchip.h | 13 ++ include/linux/irqchip/arm-gic-acpi.h | 10 +- include/linux/irqchip/arm-gic.h | 7 + include/linux/mod_devicetable.h | 8 + include/linux/pci-acpi.h | 4 + 22 files changed, 1009 insertions(+), 119 deletions(-) create mode 100644 drivers/acpi/acpi_gic.c create mode 100644 drivers/irqchip/irq-gic-acpi.c create mode 100644 include/acpi/acpi_gic.h -- 1.9.1

8 years, 8 months

[PATCH V11 0/5] map GHES memory region according to EFI memory map

by Jonathan (Zhixiong) Zhang

From: "Jonathan (Zhixiong) Zhang" <zjzhang(a)codeaurora.org> On a platform with APEI (ACPI Platform Error Interface) enabled, firmware updates a memory region with hardware error record using nocache attribute. When OS reads the region, since it maps the region with cacahed attribute even though EFI memory map defines this region as uncached, OS gets stale data and errorneously reports there is no new HW error. When ghes driver maps the memory region, it uses the cache attribute according to EFI memory map, if EFI memory map feature is enabled at runtime. Since both arch/x86 and arch/ia64 implemented architecture agnostic EFI memory map attribue lookup function efi_memattributes(), the code is moved from arch/x86 into EFI subsystem and is declared as __weak; archs other than ia64 should not override the default implementation. V11: 1. Changed how we deal with superimposed memory region attributes as provided in UEFI memory map, on arm64. V10: 1. Fixed compilation issue on x86. V9: 1. Rebased to arm64-upstream-14543 of arm64/master. 2. Match strict MM type in arch_apei_get_mem_attribute(). V8: 1. For x86, always return PAGE_KERNEL for arch_apei_get_mem_attribute(). The rational is explained in comment. 2. Rebased to arm64-upstream-14201 of arm64/master, next-20150724 of linux-next/master. V7: 1. Added PROT_DEVICE_nGnRnE and PROT_NORMAL_WT to support all possible UEFI memory types for arm64. V6: 1. Implemented arch_apei_get_mem_attributes() for arm64 as inline function. 2. Rebased to efi-next-14364 of efi/next, pm+acpi-4.2-rc3 of linux-pm/master, arm64-upstream-13521 of arm64/master, next-20150720 of linux-next/master. V5: 1. Rebased to next-20150713 of linux-next/master, efi-next-14359 of efi/next, pm+acpi-4.2-rc2 of linux-pm/master, arm64-fixes-1215 of arm64/master. 2. Added comment for efi_mem_attributes(), explained why it is marked as __weak at the function definition site. V4: 1. Introduced arch_apei_get_mem_attributes() to allow arch specific implementation of getting pgprot_t appropriate for a physical address. 2. Implemented arch_apei_get_mem_attributes() for x86 and for arm64. V3: 1. Rebased to v4.1-rc7. 2. Moved efi_mem_attributes() from arch/x86 to drivers/firmware/efi and declared it as __weak. 3. Introduced ARCH_APEI_PAGE_KERNEL_UC to allow arch specific page protection type for UC. 4. Removed efi_ioremap(). It can not be used for GHES memory region mapping purpose since ioremap can not be used in atomic context. V2: 1. Rebased to v4.1-rc5. 2. Split removal of efi_mem_attributes() and creation of efi_ioremap() into two patches. Jonathan (Zhixiong) Zhang (5): efi: x86: rearrange efi_mem_attributes() x86: acpi: implement arch_apei_get_mem_attributes() arm64: mm: add PROT_DEVICE_nGnRnE and PROT_NORMAL_WT arm64: apei: implement arch_apei_get_mem_attributes() acpi, apei: use appropriate pgprot_t to map GHES memory arch/arm64/include/asm/acpi.h | 30 ++++++++++++++++++++++++++++++ arch/arm64/include/asm/memory.h | 1 + arch/arm64/include/asm/pgtable.h | 2 ++ arch/arm64/mm/proc.S | 4 +++- arch/x86/include/asm/acpi.h | 24 ++++++++++++++++++++++++ arch/x86/platform/efi/efi.c | 18 ------------------ drivers/acpi/apei/ghes.c | 6 ++++-- drivers/firmware/efi/efi.c | 31 +++++++++++++++++++++++++++++++ 8 files changed, 95 insertions(+), 21 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

8 years, 8 months

Boot issue with the mustang topic branch

by Itaru Kitayama

Hi Al, The current HEAD of acpi topic branch boot process stops right after: EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... XhcClearBiosOwnership: called to clear BIOS ownership XhcClearBiosOwnership: called to clear BIOS ownership L3c Cache: 8MB I've been testing the topic branch on one of the Mustangs in the Linaro Server lab. The firmware version is: version 1.1.0-rh-0.15 built at 14:20:32 on Mar 13 2015. Can I have your .config you are using for ACPI testing? Itaru

8 years, 8 months

Tenemos los mejores títulos para ver en xtop

by paula

Tenemos los mejores títulos para ver en xtop Encontranos con la palabra xtop en todos los buscadores Estrenos y preestrenos: 8 APELLIDOS VASCOS AGUA ANTMAN (EL HOMBRE HORMIGA) CENIZAS DEL PASADO CERCANA OBSESION (THE BOY NEXT DOOR) CHAPPIE CIUDADES DE PAPEL (PAPER TOWNS) CON DERECHO A ROCE DE CABALLOS Y DE HOMBRES DONDE SE ESCONDE EL DIABLO (WHERE THE DEVIL HIDES) DOS DIAS UNA NOCHE (DEUX JOURS UNE NUIT) DOS LOCAS EN FUGA (HOT PURSUIT) DRAGON BALL Z RESURRECTION F (LA RESURRECCION DE FREEZER) EL AÑO MAS VIOLENTO (A MOST VIOLENT YEAR) EL GRAN PEQUEÑO (LITTLE BOY) EL GRAN SECUESTRO DE MR HEINEKEN EL GURU DE LAS BODAS (THE WEDDING RINGER) EL NUEVO EXOTICO HOTEL MARIGOLD EL PAYASO DEL MAL (CLOWN) EL SECRETO DE ADALINE EL SEPTIMO ENANITO (THE 7TH DWARF) EL ULTIMO NARUTO LA PELICULA (THE LAST NARUTO THE MOVIE) ELIMINADO (UNFRIENDED) ESCRIBIENDO DE AMOR INTENSAMENTE JESSABELLE JURASSIC WORLD (JURASSIC PARK IV) LA CASA DEL DEMONIO (DEMONIC) LA DAMA DE ORO (WOMAN IN GOLD) LA MECANICA DEL CORAZON (JACK ET LA MECANIQUE DU COEUR) LA NOCHE DEL DEMONIO 3 (INSIDIOUS) LA OVEJA SHAUN LA PELICULA LOS 33 DE SAN JOSE (33) LUGARES OSCUROS (DARK PLACES) MAD MAX 4 FURIA EN LA CARRETERA MAGIC MIKE XXL MAN ON WIRE (EL ALAMBRISTA) MIENTRAS SEAMOS JOVENES (WHILE WERE YOUNG) MIL VECES BUENAS NOCHES (A THOU SAND TIMES GOODNIGHT) MINIONS MISION IMPOSIBLE 5 NACION SECRETA NOTAS PERFECTAS 2 (PITCH PERFECT 2) PIXELES POLTERGEIST (JUEGOS DIABOLICOS) PUERTAS ADENTRO (MUSARAÑAS) RAPIDOS Y FURIOSOS 7 RESUCITADOS SHOWROOM SPY UNA ESPIA DESPISTADA TE SIGUE (IT FOLLOWS) TED 2 TERAPIA DE BROADWAY (SHES FUNNY THAT WAY) TERMINATOR 5 GENESIS TERREMOTO LA FALLA DE SAN ANDRES TOMORROWLAND EL MUNDO DEL MAÑANA TRASH (LADRONES DE ESPERANZA) TRUENO Y LA CASA MAGICA UN CASTILLO EN ITALIA (UN CHATEAU EN ITALIE) UN NUEVO DESPERTAR (THE HUMBLING) UNA NOCHE PARA SOBREVIVIR (RUN ALL NIGHT) VOLEY series DE TV : A TOUCH OF CLOTH ANTMAN (EL HOMBRE HORMIGA) COMBATE DARK MATTER DEVIOUS MAIDS DOWNTON ABBEY DR HOUSE DRAGON BALL SUPE FEAR THE WALKING DEAD GAME OF THRONES GYM TONY HEROES HUMANS INFIELES (MISTRESSES) JONATHAN STRANGE AND MR NORRELL LOS CABALLEROS DEL ZODIACO ALMA DORADA MAJOR CRIMES ORANGE IS THE NEW BLACK OUTLANDER PATITO FEO STITCHERS TEEN WOLF THE BLACKLIST THE BRINK THE FOSTERS THE MESSENGERS WAYWARD PINES ZUMBA SCULPT

8 years, 8 months

[PATCH V10 0/5] map GHES memory region according to EFI memory map

by Jonathan (Zhixiong) Zhang

From: "Jonathan (Zhixiong) Zhang" <zjzhang(a)codeaurora.org> On a platform with APEI (ACPI Platform Error Interface) enabled, firmware updates a memory region with hardware error record using nocache attribute. When OS reads the region, since it maps the region with cacahed attribute even though EFI memory map defines this region as uncached, OS gets stale data and errorneously reports there is no new HW error. When ghes driver maps the memory region, it uses the cache attribute according to EFI memory map, if EFI memory map feature is enabled at runtime. Since both arch/x86 and arch/ia64 implemented architecture agnostic EFI memory map attribue lookup function efi_memattributes(), the code is moved from arch/x86 into EFI subsystem and is declared as __weak; archs other than ia64 should not override the default implementation. V10: 1. Fixed compilation issue on x86. V9: 1. Rebased to arm64-upstream-14543 of arm64/master. 2. Match strict MM type in arch_apei_get_mem_attribute(). V8: 1. For x86, always return PAGE_KERNEL for arch_apei_get_mem_attribute(). The rational is explained in comment. 2. Rebased to arm64-upstream-14201 of arm64/master, next-20150724 of linux-next/master. V7: 1. Added PROT_DEVICE_nGnRnE and PROT_NORMAL_WT to support all possible UEFI memory types for arm64. V6: 1. Implemented arch_apei_get_mem_attributes() for arm64 as inline function. 2. Rebased to efi-next-14364 of efi/next, pm+acpi-4.2-rc3 of linux-pm/master, arm64-upstream-13521 of arm64/master, next-20150720 of linux-next/master. V5: 1. Rebased to next-20150713 of linux-next/master, efi-next-14359 of efi/next, pm+acpi-4.2-rc2 of linux-pm/master, arm64-fixes-1215 of arm64/master. 2. Added comment for efi_mem_attributes(), explained why it is marked as __weak at the function definition site. V4: 1. Introduced arch_apei_get_mem_attributes() to allow arch specific implementation of getting pgprot_t appropriate for a physical address. 2. Implemented arch_apei_get_mem_attributes() for x86 and for arm64. V3: 1. Rebased to v4.1-rc7. 2. Moved efi_mem_attributes() from arch/x86 to drivers/firmware/efi and declared it as __weak. 3. Introduced ARCH_APEI_PAGE_KERNEL_UC to allow arch specific page protection type for UC. 4. Removed efi_ioremap(). It can not be used for GHES memory region mapping purpose since ioremap can not be used in atomic context. V2: 1. Rebased to v4.1-rc5. 2. Split removal of efi_mem_attributes() and creation of efi_ioremap() into two patches. Jonathan (Zhixiong) Zhang (5): efi: x86: rearrange efi_mem_attributes() x86: acpi: implement arch_apei_get_mem_attributes() arm64: mm: add PROT_DEVICE_nGnRnE and PROT_NORMAL_WT arm64: apei: implement arch_apei_get_mem_attributes() acpi, apei: use appropriate pgprot_t to map GHES memory arch/arm64/include/asm/acpi.h | 27 +++++++++++++++++++++++++++ arch/arm64/include/asm/memory.h | 1 + arch/arm64/include/asm/pgtable.h | 2 ++ arch/arm64/mm/proc.S | 4 +++- arch/x86/include/asm/acpi.h | 24 ++++++++++++++++++++++++ arch/x86/platform/efi/efi.c | 18 ------------------ drivers/acpi/apei/ghes.c | 6 ++++-- drivers/firmware/efi/efi.c | 31 +++++++++++++++++++++++++++++++ 8 files changed, 92 insertions(+), 21 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

8 years, 8 months

[PATCH V9 0/5] map GHES memory region according to EFI memory map

by Jonathan (Zhixiong) Zhang

From: "Jonathan (Zhixiong) Zhang" <zjzhang(a)codeaurora.org> On a platform with APEI (ACPI Platform Error Interface) enabled, firmware updates a memory region with hardware error record using nocache attribute. When OS reads the region, since it maps the region with cacahed attribute even though EFI memory map defines this region as uncached, OS gets stale data and errorneously reports there is no new HW error. When ghes driver maps the memory region, it uses the cache attribute according to EFI memory map, if EFI memory map feature is enabled at runtime. Since both arch/x86 and arch/ia64 implemented architecture agnostic EFI memory map attribue lookup function efi_memattributes(), the code is moved from arch/x86 into EFI subsystem and is declared as __weak; archs other than ia64 should not override the default implementation. V9: 1. Rebased to arm64-upstream-14543 of arm64/master. 2. Match strict MM type in arch_apei_get_mem_attribute(). V8: 1. For x86, always return PAGE_KERNEL for arch_apei_get_mem_attribute(). The rational is explained in comment. 2. Rebased to arm64-upstream-14201 of arm64/master, next-20150724 of linux-next/master. V7: 1. Added PROT_DEVICE_nGnRnE and PROT_NORMAL_WT to support all possible UEFI memory types for arm64. V6: 1. Implemented arch_apei_get_mem_attributes() for arm64 as inline function. 2. Rebased to efi-next-14364 of efi/next, pm+acpi-4.2-rc3 of linux-pm/master, arm64-upstream-13521 of arm64/master, next-20150720 of linux-next/master. V5: 1. Rebased to next-20150713 of linux-next/master, efi-next-14359 of efi/next, pm+acpi-4.2-rc2 of linux-pm/master, arm64-fixes-1215 of arm64/master. 2. Added comment for efi_mem_attributes(), explained why it is marked as __weak at the function definition site. V4: 1. Introduced arch_apei_get_mem_attributes() to allow arch specific implementation of getting pgprot_t appropriate for a physical address. 2. Implemented arch_apei_get_mem_attributes() for x86 and for arm64. V3: 1. Rebased to v4.1-rc7. 2. Moved efi_mem_attributes() from arch/x86 to drivers/firmware/efi and declared it as __weak. 3. Introduced ARCH_APEI_PAGE_KERNEL_UC to allow arch specific page protection type for UC. 4. Removed efi_ioremap(). It can not be used for GHES memory region mapping purpose since ioremap can not be used in atomic context. V2: 1. Rebased to v4.1-rc5. 2. Split removal of efi_mem_attributes() and creation of efi_ioremap() into two patches. Jonathan (Zhixiong) Zhang (5): efi: x86: rearrange efi_mem_attributes() x86: acpi: implement arch_apei_get_mem_attributes() arm64: mm: add PROT_DEVICE_nGnRnE and PROT_NORMAL_WT arm64: apei: implement arch_apei_get_mem_attributes() acpi, apei: use appropriate pgprot_t to map GHES memory arch/arm64/include/asm/acpi.h | 26 ++++++++++++++++++++++++++ arch/arm64/include/asm/memory.h | 1 + arch/arm64/include/asm/pgtable.h | 2 ++ arch/arm64/mm/proc.S | 4 +++- arch/x86/kernel/acpi/apei.c | 19 +++++++++++++++++++ arch/x86/platform/efi/efi.c | 18 ------------------ drivers/acpi/apei/ghes.c | 6 ++++-- drivers/firmware/efi/efi.c | 31 +++++++++++++++++++++++++++++++ include/acpi/apei.h | 1 + 9 files changed, 87 insertions(+), 21 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

8 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-acpi August 2015