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

[Lean Sheng Tan]

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 <guo.dong at intel.com> or @Chiu, Chasel
<chasel.chiu at intel.com> could you
help to confirm on this?

Thanks.

Best Regards,
*Lean Sheng Tan*



9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
Email: sheng.tan at 9elements.com
Phone: *+49 234 68 94 188 <+492346894188>*
Mobile: *+49 176 76 113842 <+4917676113842>*

Registered office: Bochum
Commercial register: Amtsgericht Bochum, HRB 17519
Management: Sebastian German, Eray Bazaar

Data protection information according to Art. 13 GDPR
<https://9elements.com/privacy>


On Tue, 29 Aug 2023 at 23:38, Rob Herring <robh at kernel.org> wrote:

> 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
>