Hi Sheng, On Wed, 6 Sept 2023 at 08:47, Lean Sheng Tan <sheng.tan@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx > 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@xxxxxxxxxx> wrote: >> >> On Tue, Aug 29, 2023 at 2:18 PM Simon Glass <sjg@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> >> > --- >> > >> > (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
