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
-----------------------------------
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
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
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
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
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
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
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