dt-bindings: nvmem: Remove fsl,t1023-sfp in favor of fsl,layerscape-sfp

The qoriq-efuse driver is a duplicate of layerscape-sfp.c. The T-series uses TA 2.0, while Layerscape uses TA 2.1 or 3.0 (depending on the chip). Add appropriate compatibles to the layerscape-sfp driver and remove the qoriq-efuse driver. I did not add support for P-series SoCs, since they use TA 1.0 which doesn't share a major version with either of the existing implementations.

The qoriq-efuse driver does not properly abstract the location/offset of the fuses properly, instead exposing the device's whole address range to userspace. This is not appropriate, as the fuses only occupy a small portion of this range. The layerscape-sfp module correctly constrains the nvmem size to the fuses size. This represents a (necessary) compatibility break. The qoriq-efuse driver has been in-tree for around six months. Hopefully this will limit the fallout.

I would appreciate if someone with access to trust architecture 2.0 user guide could confirm the number of fuses.

Fixes 0861110bb421 ("nvmem: add new NXP QorIQ eFuse driver")

Signed-off-by Sean Anderson <[email protected]>

Quoted 15 lines · Sean Anderson

The qoriq-efuse driver is a duplicate of layerscape-sfp.c. The T-series uses TA 2.0, while Layerscape uses TA 2.1 or 3.0 (depending on the chip). Add appropriate compatibles to the layerscape-sfp driver and remove the qoriq-efuse driver. I did not add support for P-series SoCs, since they use TA 1.0 which doesn't share a major version with either of the existing implementations.

The qoriq-efuse driver does not properly abstract the location/offset of the fuses properly, instead exposing the device's whole address range to userspace. This is not appropriate, as the fuses only occupy a small portion of this range. The layerscape-sfp module correctly constrains the nvmem size to the fuses size. This represents a (necessary) compatibility break. The qoriq-efuse driver has been in-tree for around six months. Hopefully this will limit the fallout.

Quoted 5 lines

I would appreciate if someone with access to trust architecture 2.0 user guide could confirm the number of fuses.

Fixes 0861110bb421 ("nvmem: add new NXP QorIQ eFuse driver")

Signed-off-by Sean Anderson <[email protected]>

I don't think Fixes is appropriate here. Apart from that:

Acked-by Richard Alpe <[email protected]>

These bindings document the same hardware (just different minor revisions). Remove the newer fsl,t1023-sfp.

Fixes aa1ed6047107 ("dt-bindings: nvmem: Add t1023-sfp efuse support")

Signed-off-by Sean Anderson <[email protected]>

---

 .../bindings/nvmem/fsl,layerscape-sfp.yaml    | 21 ++++++++++-
 .../bindings/nvmem/fsl,t1023-sfp.yaml         | 37 -------------------
 2 files changed, 19 insertions(+), 39 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml

Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml +0 -0

index 70fb2ad25103..8a54dd1328ea 100644
@@ -19,6 +19,13 @@ allOf:
 properties:

Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml +0 -0

       - description: Trust architecture 2.1 SFP
         items:

- const: fsl,ls1021a-sfp

Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml +12 -2

@@ -45,8 +52,18 @@ properties:
 required:
   - compatible
   - reg
-  - clock-names
-  - clocks
+
+if:
+  properties:
+    compatible:
+      contains:
+        enum:
+          - fsl,ls1021a-sfp
+          - fsl,ls1028a-sfp
+then:
+  required:
+    - clocks
+    - clock-names
 
 unevaluatedProperties: false
 

Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml deleted +0 -37

deleted file mode 100644
index df826b40d8ca..000000000000
@@ -1,37 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/nvmem/fsl,t1023-sfp.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: NXP QorIQ eFuse support
-
-maintainers:
-  - Richard Alpe <[email protected]>
-
-description:
-  Read support for the eFuses (SFP) on NXP QorIQ series SoC's.
-
-allOf:
-  - $ref: nvmem.yaml#
-
-properties:
-  compatible:
-    const: fsl,t1023-sfp
-
-  reg:
-    maxItems: 1
-
-required:
-  - compatible
-  - reg
-
-unevaluatedProperties: false
-
-examples:
-  - |
-    efuse@e8000 {
-        compatible = "fsl,t1023-sfp";
-        reg = <0xe8000 0x1000>;
-    };
-...

Signature · 1 line

2.35.1.1320.gc452695387.dirty

Quoted 24 lines · Sean Anderson

These bindings document the same hardware (just different minor revisions). Remove the newer fsl,t1023-sfp.

Fixes aa1ed6047107 ("dt-bindings: nvmem: Add t1023-sfp efuse support")

Signed-off-by Sean Anderson <[email protected]>

---

 .../bindings/nvmem/fsl,layerscape-sfp.yaml    | 21 ++++++++++-
 .../bindings/nvmem/fsl,t1023-sfp.yaml         | 37 -------------------
 2 files changed, 19 insertions(+), 39 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml

Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml +4 -0

index 70fb2ad25103..8a54dd1328ea 100644
@@ -19,6 +19,13 @@ allOf:
 properties:
   compatible:
     oneOf:
+      - description: Trust architecture 2.0 SFP
+        items:
+          enum:
+            - fsl,t1023-sfp

Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml allOf: · line 28

Quoted 3 lines

Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml +3 -0

+            - fsl,t1040-sfp
+            - fsl,t2080-sfp
+            - fsl,t4240-sfp

You should at least mention where these three compatibles came from, given they were not documented in t1023-sfp.yaml

Additionally, should
they fall back to t1023-sfp? I see that there's already some dts files with these compatibles in them but seemingly no driver support as there is for the t1023-sfp.

Quoted 70 lines

Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml +12 -2

       - description: Trust architecture 2.1 SFP
         items:
           - const: fsl,ls1021a-sfp

@@ -45,8 +52,18 @@ properties:
 required:
   - compatible
   - reg
-  - clock-names
-  - clocks
+
+if:
+  properties:
+    compatible:
+      contains:
+        enum:
+          - fsl,ls1021a-sfp
+          - fsl,ls1028a-sfp
+then:
+  required:
+    - clocks
+    - clock-names
 
 unevaluatedProperties: false
 

Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml deleted +0 -37

deleted file mode 100644
index df826b40d8ca..000000000000
@@ -1,37 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/nvmem/fsl,t1023-sfp.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: NXP QorIQ eFuse support
-
-maintainers:
-  - Richard Alpe <[email protected]>
-
-description:
-  Read support for the eFuses (SFP) on NXP QorIQ series SoC's.
-
-allOf:
-  - $ref: nvmem.yaml#
-
-properties:
-  compatible:
-    const: fsl,t1023-sfp
-
-  reg:
-    maxItems: 1
-
-required:
-  - compatible
-  - reg
-
-unevaluatedProperties: false
-
-examples:
-  - |
-    efuse@e8000 {
-        compatible = "fsl,t1023-sfp";
-        reg = <0xe8000 0x1000>;
-    };
-...

Signature · 1 line

2.35.1.1320.gc452695387.dirty

Quoted 4 lines · Conor Dooley

Additionally, should
they fall back to t1023-sfp? I see that there's already some dts files with these compatibles in them but seemingly no driver support as there is for the t1023-sfp.

I checked the reference manuals for these processors, and all of them use TA 2.0.

Quoted 7 lines · Sean Anderson

Quoted 4 lines · Conor Dooley

Additionally, should
they fall back to t1023-sfp? I see that there's already some dts files with these compatibles in them but seemingly no driver support as there is for the t1023-sfp.

Quoted 1 line

I checked the reference manuals for these processors, and all of them use TA 2.0.

Sounds like a fallback is suitable then, although that will require updating the various dts files.

Quoted 10 lines · Conor Dooley

Quoted 8 lines · Sean Anderson

Quoted 4 lines · Conor Dooley

Additionally, should
they fall back to t1023-sfp? I see that there's already some dts files with these compatibles in them but seemingly no driver support as there is for the t1023-sfp.

I checked the reference manuals for these processors, and all of them use TA 2.0.

Quoted 2 lines

Sounds like a fallback is suitable then, although that will require updating the various dts files.

Yes, a fallback (like what is done for the T-series) would be suitable, but given that these devicetrees have been in-tree for eight years I think it would be preferable to support the existing bindings for compatibility purposes.

Quoted 11 lines · Sean Anderson

Quoted 10 lines · Conor Dooley

Quoted 8 lines · Sean Anderson

Quoted 4 lines · Conor Dooley

Additionally, should
they fall back to t1023-sfp? I see that there's already some dts files with these compatibles in them but seemingly no driver support as there is for the t1023-sfp.

I checked the reference manuals for these processors, and all of them use TA 2.0.

Quoted 7 lines

Quoted 2 lines

Sounds like a fallback is suitable then, although that will require updating the various dts files.

Yes, a fallback (like what is done for the T-series) would be suitable, but given that these devicetrees have been in-tree for eight years I think it would be preferable to support the existing bindings for compatibility purposes.

Just cos stuff snuck into the tree in dts files doesn't make it right though, I'd rather the bindings were done correctly. I don't care if you want to support all of the compatibles in the driver so that it works with the existing devicetrees though, as long as you mention the rationale in the commit message.

Quoted 20 lines · Conor Dooley

Quoted 18 lines · Sean Anderson

Quoted 8 lines · Conor Dooley

Quoted 7 lines · Sean Anderson

Quoted 4 lines · Conor Dooley

Additionally, should
they fall back to t1023-sfp? I see that there's already some dts files with these compatibles in them but seemingly no driver support as there is for the t1023-sfp.

Quoted 4 lines

Quoted 1 line

I checked the reference manuals for these processors, and all of them use TA 2.0.

Sounds like a fallback is suitable then, although that will require updating the various dts files.

Yes, a fallback (like what is done for the T-series) would be suitable, but given that these devicetrees have been in-tree for eight years I think it would be preferable to support the existing bindings for compatibility purposes.

Quoted 5 lines

Just cos stuff snuck into the tree in dts files doesn't make it right though, I'd rather the bindings were done correctly. I don't care if you want to support all of the compatibles in the driver so that it works with the existing devicetrees though, as long as you mention the rationale in the commit message.

It doesn't really matter what the schema has as long as the driver supports existing device trees.

Quoted 21 lines · Sean Anderson

Quoted 20 lines · Conor Dooley

Quoted 18 lines · Sean Anderson

Quoted 8 lines · Conor Dooley

Quoted 7 lines · Sean Anderson

Quoted 4 lines · Conor Dooley

Additionally, should
they fall back to t1023-sfp? I see that there's already some dts files with these compatibles in them but seemingly no driver support as there is for the t1023-sfp.

Quoted 4 lines

Quoted 1 line

I checked the reference manuals for these processors, and all of them use TA 2.0.

Sounds like a fallback is suitable then, although that will require updating the various dts files.

Yes, a fallback (like what is done for the T-series) would be suitable, but given that these devicetrees have been in-tree for eight years I think it would be preferable to support the existing bindings for compatibility purposes.

Quoted 8 lines

Quoted 5 lines

Just cos stuff snuck into the tree in dts files doesn't make it right though, I'd rather the bindings were done correctly. I don't care if you want to support all of the compatibles in the driver so that it works with the existing devicetrees though, as long as you mention the rationale in the commit message.

It doesn't really matter what the schema has as long as the driver supports existing device trees.

We do not talk about driver now but bindings. You add new compatibles on a basis that they were already used. This cannot bypass regular review comments, so if during regular review process we would require fallbacks, then you are expected to listen to review also when documenting existing compatibles. Otherwise everyone would prefer to snuck in incorrect code and later document it "it was there!".

Quoted 31 lines · Krzysztof Kozlowski

Quoted 21 lines · Sean Anderson

Quoted 20 lines · Conor Dooley

Quoted 18 lines · Sean Anderson

Quoted 8 lines · Conor Dooley

Quoted 7 lines · Sean Anderson

Quoted 4 lines · Conor Dooley

Additionally, should
they fall back to t1023-sfp? I see that there's already some dts files with these compatibles in them but seemingly no driver support as there is for the t1023-sfp.

Quoted 4 lines

Quoted 1 line

I checked the reference manuals for these processors, and all of them use TA 2.0.

Sounds like a fallback is suitable then, although that will require updating the various dts files.

Yes, a fallback (like what is done for the T-series) would be suitable, but given that these devicetrees have been in-tree for eight years I think it would be preferable to support the existing bindings for compatibility purposes.

Quoted 8 lines

Quoted 5 lines

Just cos stuff snuck into the tree in dts files doesn't make it right though, I'd rather the bindings were done correctly. I don't care if you want to support all of the compatibles in the driver so that it works with the existing devicetrees though, as long as you mention the rationale in the commit message.

It doesn't really matter what the schema has as long as the driver supports existing device trees.

Quoted 6 lines

We do not talk about driver now but bindings. You add new compatibles on a basis that they were already used. This cannot bypass regular review comments, so if during regular review process we would require fallbacks, then you are expected to listen to review also when documenting existing compatibles. Otherwise everyone would prefer to snuck in incorrect code and later document it "it was there!".

To be clear, the existing nodes look like

	sfp: sfp@e8000 {
		compatible = "fsl,t1040-sfp";
		reg	   = <0xe8000 0x1000>;
	};

which is perfectly serviceable for read-only use (as the clock is only necessary for writing). As these devices are effectively identical, the compatible could also look like what the P-series has:

	sfp: sfp@e8000 {
		compatible = "fsl,p2041-sfp", "fsl,qoriq-sfp-1.0";
		reg	   = <0xe8000 0x1000>;
	};

but in either case, it is desirable for the driver to match based on the more-specific compatible (as well as the less-specific compatible) as we already have enough information from the more-specific compatible to select the correct implementation.

--Sean

Quoted 46 lines · Sean Anderson

Quoted 31 lines · Krzysztof Kozlowski

Quoted 21 lines · Sean Anderson

Quoted 20 lines · Conor Dooley

Quoted 18 lines · Sean Anderson

Quoted 8 lines · Conor Dooley

Quoted 7 lines · Sean Anderson

Quoted 4 lines · Conor Dooley

Additionally, should
they fall back to t1023-sfp? I see that there's already some dts files with these compatibles in them but seemingly no driver support as there is for the t1023-sfp.

Quoted 4 lines

Quoted 1 line

I checked the reference manuals for these processors, and all of them use TA 2.0.

Sounds like a fallback is suitable then, although that will require updating the various dts files.

Yes, a fallback (like what is done for the T-series) would be suitable, but given that these devicetrees have been in-tree for eight years I think it would be preferable to support the existing bindings for compatibility purposes.

Quoted 8 lines

Quoted 5 lines

Just cos stuff snuck into the tree in dts files doesn't make it right though, I'd rather the bindings were done correctly. I don't care if you want to support all of the compatibles in the driver so that it works with the existing devicetrees though, as long as you mention the rationale in the commit message.

It doesn't really matter what the schema has as long as the driver supports existing device trees.

Quoted 6 lines

We do not talk about driver now but bindings. You add new compatibles on a basis that they were already used. This cannot bypass regular review comments, so if during regular review process we would require fallbacks, then you are expected to listen to review also when documenting existing compatibles. Otherwise everyone would prefer to snuck in incorrect code and later document it "it was there!".

To be clear, the existing nodes look like

	sfp: sfp@e8000 {
		compatible = "fsl,t1040-sfp";
		reg	   = <0xe8000 0x1000>;
	};

Quoted 3 lines

which is perfectly serviceable for read-only use (as the clock is only necessary for writing). As these devices are effectively identical, the compatible could also look like what the P-series has:

I'd rather you just picked the oldest device and used that as the fallback, rather than introducing an "<blah>-sfp-2.0" compatible. The 2.1 and 3.0 ones don't have anything like that.

Quoted 4 lines

	sfp: sfp@e8000 {
		compatible = "fsl,p2041-sfp", "fsl,qoriq-sfp-1.0";
		reg	   = <0xe8000 0x1000>;
	};

None of the seem to be documented either btw:
rg fsl,qoriq-sfp-1.0
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi
371: compatible = "fsl,p5020-sfp", "fsl,qoriq-sfp-1.0";

arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
339: compatible = "fsl,p2041-sfp", "fsl,qoriq-sfp-1.0";

arch/powerpc/boot/dts/fsl/p4080si-post.dtsi
386: compatible = "fsl,p4080-sfp", "fsl,qoriq-sfp-1.0";

arch/powerpc/boot/dts/fsl/p3041si-post.dtsi
366: compatible = "fsl,p3041-sfp", "fsl,qoriq-sfp-1.0";

arch/powerpc/boot/dts/fsl/p5040si-post.dtsi
331: compatible = "fsl,p5040-sfp", "fsl,qoriq-sfp-1.0";

Quoted 7 lines

but in either case, it is desirable for the driver to match based on the more-specific compatible (as well as the less-specific compatible) as we already have enough information from the more-specific compatible to select the correct implementation.

--Sean

These bindings document the same hardware (just different minor revisions). Remove the newer fsl,t1023-sfp.

Fixes aa1ed6047107 ("dt-bindings: nvmem: Add t1023-sfp efuse support")

Signed-off-by Sean Anderson <[email protected]>

---

 .../bindings/nvmem/fsl,layerscape-sfp.yaml    | 21 ++++++++++-
 .../bindings/nvmem/fsl,t1023-sfp.yaml         | 37 -------------------
 2 files changed, 19 insertions(+), 39 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml

Quoted 4 lines · Sean Anderson

These bindings document the same hardware (just different minor revisions). Remove the newer fsl,t1023-sfp.

Fixes aa1ed6047107 ("dt-bindings: nvmem: Add t1023-sfp efuse support")

I don't think Fixes is appropriate here. What was broken?