[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