[PATCH v4 4/4] memory: Add ECC property

[Rob Herring]

On Tue, Aug 29, 2023 at 2:18 PM Simon Glass <sjg at chromium.org> wrote:
>
> Some memories provides ECC correction. For software which wants to check
> memory, it is helpful to see which regions provide this feature.
>
> Add this as a property of the /memory nodes, since it presumably follows
> the hardware-level memory system.
>
> Signed-off-by: Simon Glass <sjg at chromium.org>
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - Add new patch to update the /memory nodes
>
>  dtschema/schemas/memory.yaml | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/dtschema/schemas/memory.yaml b/dtschema/schemas/memory.yaml
> index 1d74410..981af04 100644
> --- a/dtschema/schemas/memory.yaml
> +++ b/dtschema/schemas/memory.yaml
> @@ -34,7 +34,14 @@ patternProperties:
>          description:
>            For the purpose of identification, each NUMA node is associated with
>            a unique token known as a node id.
> -
> +      attr:

Kind of vague.

> +        $ref: /schemas/types.yaml#/definitions/string-array
> +        description: |
> +          Attributes possessed by this memory region:
> +
> +            "single-bit-ecc" - supports single-bit ECC
> +            "multi-bit-ecc" - supports multiple-bit ECC

"supports" means corrects or reports? Most h/w supports both, but only
reports multi-bit errors.

> +            "no-ecc" - non-ECC memory

Don't define values in free form text.

This form is difficult to validate especially when non-ECC related
attr's are added to the mix as we can't really define which
combinations are valid. For example how do we prevent:

attr = "single-bit-ecc", "multi-bit-ecc";

Or maybe that's valid? If so, how would we express that?

Why do we need "no-ecc"? Is that the same as no "attr" property?

I think it's better if we have 'ecc-type' or something? Or generally,
a property per class/type of attribute.

Rob