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>] [day] [month] [year] [list]

Message-ID: <CAPnjgZ2NacjTmMB4fUL+ttAmMvn+3oJS8fA+Lu94zgMOt4rKCw@mail.gmail.com>
Date:   Wed, 6 Sep 2023 08:48:16 -0600
From:   Simon Glass <sjg@...omium.org>
To:     Lean Sheng Tan <sheng.tan@...ements.com>
Cc:     Rob Herring <robh@...nel.org>, 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>,
        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

Hi Sheng,

On Wed, 6 Sept 2023 at 08:47, Lean Sheng Tan <sheng.tan@...ements.com> wrote:
>
> Hi Rob,
> Sorry for missing this:
> regarding your question on whether if the memory can support both single-bit and multi-bit ECC, i think the answer is yes.
> @Dong, Guo or @Chiu, Chasel could you help to confirm on this?

I sent a v5 series which breaks these out into separate properties.

Regards,
Simon

>
> Thanks.
>
> Best Regards,
> Lean Sheng Tan
>
>
>
> 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
> Email: sheng.tan@...ements.com
> Phone: +49 234 68 94 188
> Mobile: +49 176 76 113842
>
> Registered office: Bochum
> Commercial register: Amtsgericht Bochum, HRB 17519
> Management: Sebastian German, Eray Bazaar
>
> Data protection information according to Art. 13 GDPR
>
>
> On Tue, 29 Aug 2023 at 23:38, Rob Herring <robh@...nel.org> wrote:
>>
>> 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