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_JsqKEbqUtWHpHXmiDSZBY7-Nw4-fLs23BEqomBevSDNBprQ@mail.gmail.com>
Date:   Thu, 7 Sep 2023 11:58:07 -0500
From:   Rob Herring <robh@...nel.org>
To:     Simon Glass <sjg@...omium.org>
Cc:     devicetree@...r.kernel.org,
        Maximilian Brune <maximilian.brune@...ements.com>,
        ron minnich <rminnich@...il.com>,
        Tom Rini <trini@...sulko.com>,
        Dhaval Sharma <dhaval@...osinc.com>,
        U-Boot Mailing List <u-boot@...ts.denx.de>,
        Mark Rutland <mark.rutland@....com>,
        Yunhui Cui <cuiyunhui@...edance.com>,
        linux-acpi@...r.kernel.org, Ard Biesheuvel <ardb@...nel.org>,
        Gua Guo <gua.guo@...el.com>,
        Lean Sheng Tan <sheng.tan@...ements.com>,
        Guo Dong <guo.dong@...el.com>,
        lkml <linux-kernel@...r.kernel.org>,
        Chiu Chasel <chasel.chiu@...el.com>
Subject: Re: [PATCH v5 4/4] memory: Add ECC properties

On Wed, Aug 30, 2023 at 6:18 PM Simon Glass <sjg@...omium.org> wrote:
>
> Some memories provide ECC detection and/or 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>
> ---
>
> Changes in v5:
> - Redo to make this property specific to ECC
> - Provide properties both for detection and correction
>
> Changes in v3:
> - Add new patch to update the /memory nodes
>
>  dtschema/schemas/memory.yaml | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)
>
> diff --git a/dtschema/schemas/memory.yaml b/dtschema/schemas/memory.yaml
> index 1d74410..944aa9f 100644
> --- a/dtschema/schemas/memory.yaml
> +++ b/dtschema/schemas/memory.yaml
> @@ -34,7 +34,37 @@ patternProperties:
>          description:
>            For the purpose of identification, each NUMA node is associated with
>            a unique token known as a node id.
> +      ecc-detection:
> +        $ref: /schemas/types.yaml#/definitions/string
> +        enum:
> +          - none
> +          - single-bit
> +          - multi-bit
> +        description: |
> +          If present, this inidcates the type of memory errors which can be

typo

> +          detected and reported by the Error-Correction Code (ECC) memory
> +          subsystem:
>
> +            none       - No error detection is possible
> +            single-bit - Detects and reports single-bit ECC errors
> +            multi-bit  - Detects and reports multiple-bit ECC errors

I don't think 'multi' is specific enough. Perhaps this should be an
int instead with how many bits. (And '-bits' is a standard unit suffix
so a type isn't needed)

> +
> +          If not present, this is equivalent to 'none'.

Can be expressed as schema:

default: none

Though if that's the default why have it as a value? (It's fine though)

> +      ecc-correction:
> +        $ref: /schemas/types.yaml#/definitions/string
> +        enum:
> +          - none
> +          - single-bit
> +          - multi-bit
> +        description: |
> +          If present, this inidcates the type of memory errors which can be

typo

> +          corrected by the Error-Correction Code (ECC) memory subsystem:
> +
> +            none       - No error correction is possible
> +            single-bit - Corrects single-bit ECC errors
> +            multi-bit  - Corrects multiple-bit ECC errors
> +
> +          If not present, this is equivalent to 'none'.

One issue is with 2 properties nonsensical combinations are allowed.
Not really any way to handle that in the schema though.

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ