This is re-use existing patch submitted by Huang Ying <ying.huang(a)intel.com>
with one small modification (see commits). The first idea was to use just
printk to inform about any errors that were not consumed by OS.
Errors listed in HEST table should point to the same "Error status block" ESB
structures as BERT does. OS handling errors should clear errors status bit
in ESB for given error at the end of error recovery procedure. Case where error
appeared to be too serious OS can reset machine immediately without clearing
bit in ESB. During boot, kernel examine each error status bit from ESB list
(pointed from BERT) and see if there are any unhandled errors.
BERT table was tested along with HEST and EINJ driver, in the following way:
1. Fill in ESB using EINJ hacked driver and do not clear erros status in ESB,
this way unhandler error is simulated and BERT table could be used later:
root@localhost:~# echo 1 > /sys/kernel/debug/apei/einj/error_inject
2. Reboot machin and check whether BERT driver notice injected error:
...
[ 2.518179] [Hardware Error]: Error record from previous boot:
[ 2.523342] [Hardware Error]: APEI generic hardware error status
[ 2.548457] [Hardware Error]: severity: 1, fatal
[ 2.574705] [Hardware Error]: section: 0, severity: 0, recoverable
[ 2.584010] [Hardware Error]: flags: 0x00
[ 2.587937] [Hardware Error]: section_type: memory error
...
3. Kernel clear status bit so next boot would not print it again.
From: Al Stone <ahs3(a)redhat.com>
I should have sent these out for comment much sooner. Once these are
in good shape, the next steps are to send patches for verifying that
the pinconf code is working properly, connecting up the GPIO interrupts
using ACPI, and then conversion of all of the pin controllers for
Arndale (this patch converts one of four).
This patch puts most of the infrastructure in place so that in the
3.11 kernel the Arndale pin controllers can be converted from FDT to
ACPI. The changes in ASL are included in a separate patch. What this
allows is for the pin controllers to be described in either FDT or ACPI
for Arndale and -- in conjunction with the ASL changes -- shows how to
describe a Samsung controller in ACPI.
Changes for v2:
-- Add patch 6 which allows compilation regardless of whether
CONFIG_ACPI is used or not
Al Stone (6):
ACPI: ARM: arndale: remove GPZ GPIO definition from DT so it can be in
ACPI
ACPI: ARM: arndale: whitelist the samsung-pinctrl driver for ACPI
ACPI: make an error message a little clearer
ACPI: improve acpi_extract_package() utility
ACPI: ARM: arndale: enable ACPI in the Samsung pinctrl driver
ACPI: ARM: arndale: add CONFIG_ACPI ifdef's to pinctrl driver
arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 2 +
arch/arm/boot/dts/exynos5250.dtsi | 6 +-
drivers/acpi/acpi_platform.c | 3 +
drivers/acpi/osl.c | 2 +-
drivers/acpi/utils.c | 17 +-
drivers/pinctrl/pinctrl-samsung.c | 517 +++++++++++++++++++++++++++++-
drivers/pinctrl/pinctrl-samsung.h | 3 +
7 files changed, 536 insertions(+), 14 deletions(-)
--
1.8.3.1
Hi everyone,
I read the wiki about ACPI Table Prioritization:
https://wiki.linaro.org/LEG/Engineering/Kernel/ACPI/TablePriorities
and I noticed that CSRT is in the *Never Tables* priority, here I got
some different opinions.
Yes, CSRT or Core System Resources Table is a proprietary ACPI table
introduced by Microsoft, but This table can contain devices that are not in
the system DSDT table. In particular DMA controllers, Timer, interrupt might
be described here.
we can get DMA description from DMAR (DMA Remapping Table) tables on Intel platform,
but on ARM SoCs, there is no table to describe DMA, only CSRT is available.
Actually, the support code of CSRT in Linux kernel already have submitted
by Intel on Jan 17 this year, but only DMA is supported, still have something
more to do (if needed).
So, why not use the CSRT table to describe DMA?
Thanks
Hanjun
From: Al Stone <ahs3(a)redhat.com>
This adds another GPIO/pinctrl device to Arndale. In the process,
logic errors in the portions of the Samsung pinctrl driver that
were using ACPI were weeded out.
Al Stone (2):
ACPI: ARM: arndale: move GPIO controller 3 of 4 from FDT to ACPI
ACPI: ARM: arndale: Enable pinctrl for configuring many controllers
via ACPI
arch/arm/boot/dts/exynos5250-arndale.dts | 26 +++++++++++++++
arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 2 +-
arch/arm/boot/dts/exynos5250.dtsi | 6 ++--
drivers/pinctrl/pinctrl-samsung.c | 53 ++++++++++++++++---------------
4 files changed, 59 insertions(+), 28 deletions(-)
--
1.8.3.1
The early_init_dt_scan_acpi() function currently uses be32_to_cpu()
helpers to read the "linux,acpi-start" and "linux,acpi-len" properties.
This may not be safe for arm64. This patch uses of_read_ulong to read
the property values which should be safe for both arm and arm64.
Signed-off-by: Mark Salter <msalter(a)redhat.com>
---
drivers/of/fdt.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 875a4c1..d48ab6a 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -720,13 +720,13 @@ int __init early_init_dt_scan_acpi(unsigned long node, const char *uname,
/* Retrieve acpi,address line */
pinfo = (struct acpi_arm_root *)data;
p = of_get_flat_dt_prop(node, "linux,acpi-start", &l);
- if (p != NULL && l > 0)
- pinfo->phys_address = be32_to_cpu(*p);
+ if (p)
+ pinfo->phys_address = of_read_ulong(p, l/4);
/* Retrieve acpi,size line */
p = of_get_flat_dt_prop(node, "linux,acpi-len", &l);
- if (p != NULL && l > 0)
- pinfo->size = be32_to_cpu(*p);
+ if (p)
+ pinfo->size = of_read_ulong(p, l/4);
return 1;
}
--
1.8.3.1