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.d...@intel.com> or @Chiu, Chasel <chasel.c...@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....@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 <r...@kernel.org> wrote: > On Tue, Aug 29, 2023 at 2:18 PM Simon Glass <s...@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 <s...@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 >
