13 Nov, 2017
1 commit
-
* acpi-pmic:
ACPI / PMIC: Add TI PMIC TPS68470 operation region driver* acpi-apei:
APEI / ERST: use 64-bit timestamps
ACPI / APEI: Remove arch_apei_flush_tlb_one()
arm64: mm: Remove arch_apei_flush_tlb_one()
ACPI / APEI: Remove ghes_ioremap_area
ACPI / APEI: Replace ioremap_page_range() with fixmap
ACPI / APEI: remove the unused dead-code for SEA/NMI notification type
ACPI / APEI: adjust a local variable type in ghes_ioremap_pfn_irq()* acpi-x86:
ACPI / x86: Extend KIOX000A quirk to cover all affected BIOS versions
07 Nov, 2017
1 commit
-
Nothing calls arch_apei_flush_tlb_one() anymore, instead relying on
__set_pte_vaddr() to do the invalidation when called from clear_fixmap()
Remove arch_apei_flush_tlb_one().Signed-off-by: James Morse
Reviewed-by: Borislav Petkov
Signed-off-by: Rafael J. Wysocki
Cc: All applicable
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
30 Aug, 2017
1 commit
-
According to the ACPI specification, firmware is not required to provide
the Hardware Error Source Table (HEST). When HEST is not present, the
following superfluous message is printed to the kernel boot log -[ 3.460067] GHES: HEST is not enabled!
Extend hest_disable variable to track whether the firmware provides this
table and if it is not present skip any log output. The existing
behaviour is preserved in all other cases.Suggested-by: Borislav Petkov
Signed-off-by: Punit Agrawal
Reviewed-by: Borislav Petkov
Signed-off-by: Rafael J. Wysocki
23 Jul, 2014
2 commits
-
GHES currently maps two pages with atomic_ioremap. From now
on, NMI is architectural depended so there is no need to allocate
an NMI page for platforms without NMI support.To make it possible to not use a second page, swap the existing
page order so that the IRQ context page is first, and the optional
NMI context page is second. Then, use HAVE_ACPI_APEI_NMI to decide
how many pages are to be allocated.Signed-off-by: Tomasz Nowicki
Acked-by: Borislav Petkov
Signed-off-by: Tony Luck -
This commit abstracts MCE calls and provides weak corresponding default
implementation for those architectures which do not need arch specific
actions. Each platform willing to do additional architectural actions
should provides desired function definition. It allows us to avoid wrap
code into #ifdef in generic code and prevent new platform from introducing
dummy stub function too.Initially, there are two APEI arch-specific calls:
- arch_apei_enable_cmcff()
- arch_apei_report_mem_error()
Both interact with MCE driver for X86 architecture.Signed-off-by: Tomasz Nowicki
Acked-by: Borislav Petkov
Signed-off-by: Tony Luck
13 Jan, 2012
1 commit
-
module_param(bool) used to counter-intuitively take an int. In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.It's time to remove the int/unsigned int option. For this version
it'll simply give a warning, but it'll break next kernel version.Acked-by: Mauro Carvalho Chehab
Signed-off-by: Rusty Russell
03 Aug, 2011
1 commit
-
as GHES is optional...
When # CONFIG_ACPI_APEI_GHES is not set:
(.init.text+0x4c22): undefined reference to `ghes_disable'
Reported-by: Randy Dunlap
Acked-by: Randy Dunlap
Signed-off-by: Len Brown
14 Jul, 2011
1 commit
-
Some machine may have broken firmware so that GHES and firmware first
mode should be disabled. This patch adds support to that.Signed-off-by: Huang Ying
Reviewed-by: Andi Kleen
Reviewed-by: Matthew Garrett
Signed-off-by: Len Brown
22 Mar, 2011
1 commit
-
APEI ERST firmware interface and implementation has no multiple users
in mind. For example, if there is four records in storage with ID: 1,
2, 3 and 4, if two ERST readers enumerate the records via
GET_NEXT_RECORD_ID as follow,reader 1 reader 2
1
2
3
4
-1
-1where -1 signals there is no more record ID.
Reader 1 has no chance to check record 2 and 4, while reader 2 has no
chance to check record 1 and 3. And any other GET_NEXT_RECORD_ID will
return -1, that is, other readers will has no chance to check any
record even they are not cleared by anyone.This makes raw GET_NEXT_RECORD_ID not suitable for used by multiple
users.To solve the issue, an in-memory ERST record ID cache is designed and
implemented. When enumerating record ID, the ID returned by
GET_NEXT_RECORD_ID is added into cache in addition to be returned to
caller. So other readers can check the cache to get all record ID
available.Signed-off-by: Huang Ying
Reviewed-by: Andi Kleen
Signed-off-by: Len Brown
15 Jan, 2011
1 commit
-
Move the evaluation of acpi_pci_osc_control_set() (to request control of
PCI Express native features) into acpi_pci_root_add() to avoid calling
it many times for the same root complex with the same arguments.
Additionally, check if all of the requisite _OSC support bits are set
before calling acpi_pci_osc_control_set() for a given root complex.References: https://bugzilla.kernel.org/show_bug.cgi?id=20232
Reported-by: Ozan Caglayan
Tested-by: Ozan Caglayan
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes
20 May, 2010
2 commits
-
ERST is a way provided by APEI to save and retrieve hardware error
record to and from some simple persistent storage (such as flash).The Linux kernel support implementation is quite simple and workable
in NMI context. So it can be used to save hardware error record into
flash in hardware error exception or NMI handler, where other more
complex persistent storage such as disk is not usable. After saving
hardware error records via ERST in hardware error exception or NMI
handler, the error records can be retrieved and logged into disk or
network after a clean reboot.For more information about ERST, please refer to ACPI Specification
version 4.0, section 17.4.This patch incorporate fixes from Jin Dongming.
Signed-off-by: Huang Ying
Signed-off-by: Andi Kleen
CC: Jin Dongming
Signed-off-by: Len Brown -
HEST describes error sources in detail; communicating operational
parameters (i.e. severity levels, masking bits, and threshold values)
to OS as necessary. It also allows the platform to report error
sources for which OS would typically not implement support (for
example, chipset-specific error registers).HEST information may be needed by other subsystems. For example, HEST
PCIE AER error source information describes whether a PCIE root port
works in "firmware first" mode, this is needed by general PCIE AER
error subsystem. So a public HEST tabling parsing interface is
provided.Signed-off-by: Huang Ying
Signed-off-by: Andi Kleen
Signed-off-by: Len Brown