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