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

[Jonathan Cameron <jic23@kernel.org>]

On Fri, 29 May 2026 10:50:49 +0100
Ahmed Tiba <ahmed.tiba@arm.com> wrote:

> Describe the DeviceTree node that exposes the Arm firmware-first
> CPER provider and hook the file into MAINTAINERS so the
> binding has an owner.

Odd wrap. Pick a length (72 / 75 typical for commit messages) and
stick to it.

Request for references inline + a question on whether we have
to allow for the ack register not existing. I'd rather we required
it if possible.

> 
> Signed-off-by: Ahmed Tiba <ahmed.tiba@arm.com>
> ---
>  .../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@arm.com>
> +
> +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.

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


> diff --git a/MAINTAINERS b/MAINTAINERS
> index 461a3eed6129..8a9714603a7d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -22261,6 +22261,11 @@ M:	Alexandre Bounine <alex.bou9@gmail.com>
>  S:	Maintained
>  F:	drivers/rapidio/
>  
> +RAS ERROR STATUS
> +M:	Ahmed Tiba <ahmed.tiba@arm.com>
> +S:	Maintained
> +F:	Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml
> +
>  RAS INFRASTRUCTURE
>  M:	Tony Luck <tony.luck@intel.com>
>  M:	Borislav Petkov <bp@alien8.de>
>