[PATCH 10/12] dt-bindings: ras: document estatus provider

Ahmed Tiba ahmed.tiba at arm.com
Wed Dec 17 09:49:27 PST 2025


On 17/12/2025 12:41, Krzysztof Kozlowski wrote:
> What is ras? There is no such directory so some description would be
> useful. Usually you do not get your own directory per binding.

Would it make sense to move it under `Documentation/devicetree/bindings/firmware`
and expand the description so it spells out that
Arm RAS refers to reliability, availability and serviceability firmware.

> Do not describe what the binding does. Describe the hardware or firmware.

I'll reword that section.

> Again ras - what's that? Your patch or binding must explain that.

I'll add that explanation to the description.

> Why is this flexible?

Some platforms only expose the CPER status buffer, while others also expose a
doorbell that firmware expects to toggle before writing the next record.
I'll keep `reg` at 1-2 entries but make the description clear about which
region is optional.

> Does not match reg.

`reg-names` will only be allowed when both regions are present,
and in that case it must list `"status", "ack"`
so the entries line up with `reg`.
If only the status buffer exists, the property stays omitted.


> What OS is doing should not really matter. Either you have the interrupt
> or not.

I’ll trim the wording so it just states that firmware
may assert an interrupt when a new record is ready.


> That's OS policy, not suitable for binding.

I’ll drop `poll-interval` from the binding and let the driver fall back
to a fixed polling interval when no interrupt is wired.

> This is implied by the compatible, no?

I’ll drop `arm,sea-notify` so the compatible alone defines the behaviour.

> Drop all this.

I’ll delete the `allOf` clauses once the policy properties are gone.

> I do not see any schema referenced.

I’ll switch from `unevaluatedProperties` to `additionalProperties: false`.

> Node names should be generic. See also an explanation and list of
> examples (not exhaustive) in DT specification:
> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
> If you cannot find a name matching your device, please check in kernel
> sources for similar cases or you can grow the spec (via pull request to
> DT spec repo).

I’ll rename the example node to `estatus at fe800000`
so it describes the firmware error-status block rather than using the driver name.

> Use proper defines.

I’ll update the example to use `GIC_SPI` and the `IRQ_TYPE_*` macros for the interrupt specifier.

Best regards,
Ahmed



More information about the linux-arm-kernel mailing list