Linaro-acpi

linaro-acpi@lists.linaro.org

820 discussions

[RFC] Discussions about _DSD and device properties

by Al Stone

I thought I would pass on some of the discussion that's going on around the use and definition of _DSD device properties. There seems to be some basic agreement that (a) we should send things to a common forum for review and documentation, and that (b) the forum needs to be easily visible and usable by Linux folks, MS people, and firmware developers, and that (c) there is a dsd(a)acpica.org mailing list set up for that, but has not been used at all (nor has the ASWG process, for that matter). Darren Hart of Intel has proposed some of these, and has volunteered to try to get this going. And, I agree with him on where we need to go with all of this. So, I would encourage people to start submitting things to the dsd(a)acpica.org mailing list. But, that begs the question of *what* to submit. I haven't been very vocal about this just because I was fiddling around with the ideas but I think they're solid enough to get moving. Please see the git tree at https://github.com/ahs3/dsd. This may or may not be the right long term place to host it, but the README describes the idea -- I've written a tool that uses simple YAML to describe device properties. The tool can verify that all the right things are documented, and allows one to build a data base -- of plain human-readable ASCII YAML -- that anyone can visit, peruse, or offer updates to. The YAML is probably not complete; however, the key thing is that this is completely open source, under a very permissive license, and easily seen or used by developers of any OS or any bit of firmware -- the neutral location and open license means equal use and access for Microsoft, Linux, and the firmware writers. Patches are of course welcome -- to the tool, or even the data base of device property descriptions. So, if one sends the type of YAML expected to dsd(a)acpica.org, I can easily pull it in, verify it, and push it back out to github, assuming it's reasonably correct and usable. If we can agree that all discussions about the acceptability of any particular device property occurs on dsd(a)acpica.org, we can get this process moving and documented, and change the discussion to be about specific device properties instead. I'm attaching the README from https://github.com/ahs3/dsd for those that are as lazy as I am about following links :)..... README ------ dsd -- a command line tool for _DSD device property registrations ----------------------------------------------------------------- A simple 'make' will produce a command line tool to help in the collection, registration and maintenance of entries describing the device properties allowed via the _DSD method in ACPI [0] -- and in Device Tree (DT). The issue is that there is a desire to share device properties not only across devices (e.g., is more than one "mac-address" really needed?), but between the users of ACPI via _DSD, and possibly the users of Device Tree (DT), where the key-value model is used extensively. While DT documentation seems to be reasonably well cared for (at least in the Linux kernel documentation) and there is a process for maintaining the device property definitions, the same is not true of ACPI. In fact, device properties as used by _DSD are maintained completely outside of the specification, and there is no history of maintaining -- or registering -- them as there is for DT, since this is all relatively new to ACPI. However, regardless of its quality, keeping documentatation in the Linux kernel does present some problems. For one, firmware developers are not likely to look at the Linux source for information on the device properties they might want to use or need to define. The OS is not really where their focus lies. For two, sharing device properties with the Windows OS becomes very difficult; asking Microsoft engineers to go use the Linux source code as reference material puts them in an untenable position. What this tool -- dsd -- is attempting to do is provide a standard, neutral location and format for the definition of these properties, so that anyone that needs to can easily get to them, register new ones, or share existing properties. Each device property is described in YAML (examples below, with details in the file called YAML). At present, a directory contains the YAML, with one file per device property, one file per device using those properties, and acts as a very crude "data base" for all of the entries. The dsd command provides several functions for dealing with this "data base" of device properties: -- initialize the data base -- verify the YAML is correct -- add the device property to the data base in a consistent format -- remove a device property from the data base -- list all known device property names -- output the info from a given device property -- output a basic text description of the property for use in Linux documentation (or elsewhere) Additional functions can be added (all the source is provided), and should this project work out, more will be -- for example, summaries of all of the properties for a given device, or analysis indicating whether or not a property is needed and by what devices, or perhaps even more clever things. Building the tool ----------------- The dsd command requires that libyaml for C be installed [1]. Then, just do: % make There is no install target at present. Run the command: % ./dsd help to show what options are available. YAML ---- The dsd command uses basic YAML formatting (so, spaces for indentation, then indentation for indicating structure) and currently recognizes the following keywords: property: <name> owner: <string> type: integer | hexadecimal-integer | hexadecimal-address-package | string | <type> <value-list> description: <free text> example: <free text> For example: property: phy-mode owner: Al Stone <ahs3(a)redhat.com> type: string values: - token: na description: none available - token: mii description: media independent interface (MII) - token: gmii description: gigabit MII - token: sgmii description: serial gigabit MII - token: tbi description: ten bit interface - token: revmii description: reverse MII - token: rmii description: reduced MII - token: rgmii description: reduced gigabit MII (RGMII) - token: rgmii-id description: RGMII with internal delay - token: rgmii-rxid description: RGMII with receive delay only - token: rgmii-txid description: RGMII with transmit delay only - token: rtbi description: reduced ten bit interface - token: smii description: serial MII - token: xgmii description: 10 gigabit MII - token: moca description: multimedia over coax - token: qsgmii description: quad serial gigabit MII description: | Defines the PHY mode to be used for this device. example: | Package (2) { "phy-mode", "xgmii" } Please use '---' to separate device property definitions if several are included in a single file of text (dsd will separate them into unique entries in the "data base"). References ---------- [0] For a description of _DSD, see: http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide… For the device properties UUID of _DSD, see: http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UU… [1] On Debian: apt-get install libyaml-dev On Fedora: dnf install libyaml-devel -- ciao, al ----------------------------------- Al Stone Software Engineer Linaro Enterprise Group al.stone(a)linaro.org -----------------------------------

9 years, 8 months

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

9 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

9 years, 9 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

9 years, 9 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

9 years, 9 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

9 years, 9 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

9 years, 9 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

9 years, 9 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

9 years, 9 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

9 years, 9 months

← Newer
1
...
18
19
20
21
22
23
24
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-acpi