Re: [PATCH v5 09/10] dt-bindings: firmware: add arm,ras-cper

[Ahmed Tiba]

On 29/05/2026 17:44, Jonathan Cameron wrote:
> On Fri, 29 May 2026 10:50:49 +0100
> Ahmed Tiba<ahmed.tiba@xxxxxxx> 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<ahmed.tiba@xxxxxxx>
> > +
> > +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