linux-kernel - Re: [PATCH v4 4/4] memory: Add ECC property

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAL_JsqLFX9PpMcJBv2yZXRpQyQ-h1DrGyApE0+AAYN2LCCj7Kg@mail.gmail.com>
Date:   Tue, 29 Aug 2023 16:37:51 -0500
From:   Rob Herring <robh@...nel.org>
To:     Simon Glass <sjg@...omium.org>
Cc:     devicetree@...r.kernel.org, Dhaval Sharma <dhaval@...osinc.com>,
        Mark Rutland <mark.rutland@....com>,
        Gua Guo <gua.guo@...el.com>, Tom Rini <trini@...sulko.com>,
        U-Boot Mailing List <u-boot@...ts.denx.de>,
        ron minnich <rminnich@...il.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Lean Sheng Tan <sheng.tan@...ements.com>,
        Maximilian Brune <maximilian.brune@...ements.com>,
        Chiu Chasel <chasel.chiu@...el.com>,
        lkml <linux-kernel@...r.kernel.org>,
        Yunhui Cui <cuiyunhui@...edance.com>,
        linux-acpi@...r.kernel.org, Guo Dong <guo.dong@...el.com>
Subject: Re: [PATCH v4 4/4] memory: Add ECC property

On Tue, Aug 29, 2023 at 2:18 PM Simon Glass <sjg@...omium.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@...omium.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