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

[Simon Glass <sjg@chromium.org>]

Hi Sheng,

On Wed, 6 Sept 2023 at 08:47, Lean Sheng Tan <sheng.tan@9elements.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@9elements.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@kernel.org> wrote:
>>
>> On Tue, Aug 29, 2023 at 2:18 PM Simon Glass <sjg@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@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