Re: [PATCH 1/6] dt-bindings: edac: altera: Document additional ECC instances
From: Niravkumar L Rabara
Date: Fri Oct 31 2025 - 04:01:56 EST
On 29/10/2025 2:50 pm, Krzysztof Kozlowski wrote:
On Tue, Oct 28, 2025 at 05:22:27PM +0800,niravkumarlaxmidas.rabara@xxxxxxxxxx wrote:
From: Niravkumar L Rabara<niravkumarlaxmidas.rabara@xxxxxxxxxx>No, list the interrupts instead. Your commit msg must clearly explain
Add support for Secure Device Manager(SDM) QSPI ECC, IO96B memory
controller ECC and Configuration RAM(CRAM) Single Event Upset(SEU).
Add interrupt-names property and increase interrupts maxItems from 2 to 7
to accommodate additional interrupts.
Signed-off-by: Niravkumar L Rabara<niravkumarlaxmidas.rabara@xxxxxxxxxx>
---
.../edac/altr,socfpga-ecc-manager.yaml | 77 ++++++++++++++++++-
1 file changed, 76 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/edac/altr,socfpga-ecc-manager.yaml b/Documentation/devicetree/bindings/edac/altr,socfpga-ecc-manager.yaml
index 3d787dea0f14..5e0c08a15ab9 100644
--- a/Documentation/devicetree/bindings/edac/altr,socfpga-ecc-manager.yaml
+++ b/Documentation/devicetree/bindings/edac/altr,socfpga-ecc-manager.yaml
@@ -33,7 +33,13 @@ properties:
interrupts:
minItems: 1
- maxItems: 2
+ maxItems: 7
why exception of not-fixed length/entries is justified.
See writing bindings.
+Nope, list the items instead. Please do not come up with some custom
+ interrupt-names:
+ items:
+ enum: [global_sbe, global_dbe, io96b0, io96b1, sdm_qspi_sbe, sdm_qspi_dbe, sdm_seu]
syntax.
+ minItems: 1Missing description, so difficult to say what is here.
+ maxItems: 7
interrupt-controller: true
@@ -70,6 +76,41 @@ properties:
- interrupts
- altr,sdr-syscon
+ cram-seu:
Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2- devicetree-basics.html#generic-names-recommendation
If you cannot find a name matching your device, please check in kernel
sources for similar cases or you can grow the spec (via pull request to
DT spec repo).
+ type: objectWhy do you need compatible?
+ additionalProperties: false
+
+ properties:
+ compatible:
+ items:
+ - const: altr,socfpga-cram-seu
+So you created child node only for reg? No, fold it into parent.
+ reg:
+ maxItems: 1
You also forgot to update the example.
+How are these board-level properties?
+ altr,seu-safe-inject-ce-msb:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: MSB of error injection command for Correctable Error
+
+ altr,seu-safe-inject-ce-lsb:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: LSB of error injection command for Correctable Error
+
+ altr,seu-safe-inject-ue-msb:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: MSB of error injection command for Uncorrectable Error
+
+ altr,seu-safe-inject-ue-lsb:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: LSB of error injection command for Uncorrectable Error
+No, drop.
+ required:
+ - compatible
+ - altr,seu-safe-inject-ce-msb
+ - altr,seu-safe-inject-ce-lsb
+ - altr,seu-safe-inject-ue-msb
+ - altr,seu-safe-inject-ue-lsb
+
patternProperties:
"^ocram-ecc@[a-f0-9]+$":
type: object
@@ -191,6 +232,40 @@ patternProperties:
- interrupts
- altr,ecc-parent
+ "^sdm-qspi-ecc@[a-f0-9]+$":
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ items:
+ - const: altr,socfpga-sdm-qspi-ecc
+No point for empty children. One reg is not justification for having a
+ reg:
+ maxItems: 1
+
+ required:
+ - compatible
+ - reg
child.
+You need to stop coming with random node names. Nothing explains why you
+ "^io96b[0-9]-ecc@[a-f0-9]+$":
need children, why these are not part of parent node.
+ type: objectPlus all your compatibles have WRONG format. See writing bindings and
+ additionalProperties: false
+
+ properties:
+ compatible:
+ items:
+ - enum:
+ - altr,socfpga-io96b0-ecc
+ - altr,socfpga-io96b1-ecc
numerouse presentations - you always must use SoC specific compatible.
Best regards,
Krzysztof
Hi Krzysztof,
Thanks for the review and feedback on the patch series.
I’ll go through your comments and address them in the next patch revision.
Thanks,
Nirav