Hi Sheng,
On Wed, 6 Sept 2023 at 08:47, Lean Sheng Tan sheng.tan@9elements.com 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@9elements.com 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@kernel.org wrote:
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 memoryDon'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