Re: [PATCH v5 09/10] dt-bindings: firmware: add arm,ras-cper
Ahmed Tiba <[email protected]>
| Newsgroups | org.kernel.vger.linux-edac,dev.linux.lists.acpica-devel,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-acpi,org.kernel.vger.linux-cxl,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 29/05/2026 17:44, Jonathan Cameron wrote: > On Fri, 29 May 2026 10:50:49 +0100 > Ahmed Tiba<[email protected]> wrote: >> .../devicetree/bindings/firmware/arm,ras-cper.yaml | 54 ++++++++++++++++++++++ >> MAINTAINERS | 5 ++ >> 2 files changed, 59 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml b/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml >> new file mode 100644 >> index 000000000000..3d4de096093f >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml >> @@ -0,0 +1,54 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id:http://devicetree.org/schemas/firmware/arm,ras-cper.yaml# >> +$schema:http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Arm RAS CPER provider >> + >> +maintainers: >> + - Ahmed Tiba<[email protected]> >> + >> +description: >> + Arm Reliability, Availability and Serviceability (RAS) firmware can expose >> + a firmware-first CPER error source directly via DeviceTree. Firmware >> + provides the CPER Generic Error Status block and notifies the OS through >> + an interrupt. > I'd like some spec references in here if possible. I can add a reference to the UEFI CPER specification for the Generic Error Status record format. For the firmware-first DT description itself I do not have a more specific public reference to cite. >> + >> +properties: >> + compatible: >> + const: arm,ras-cper >> + >> + memory-region: >> + minItems: 1 >> + items: >> + - description: >> + CPER Generic Error Status block exposed by firmware. >> + - description: >> + Optional firmware-owned ack buffer used on platforms >> + where firmware needs an explicit "ack" handshake before overwriting >> + the CPER buffer. Firmware watches bit 0 and expects the OS to set it >> + once the current status block has been consumed. > Does the arm spec really make this optional? Can we constraint it to not be > just to make our lives easier? I've never been sure how you would actually > make a working platform without the ack support. I will update the binding to require both memory-region entries. Best regards, Ahmed