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
