Skip to contentSkip to conversation

Add sata nodes to rk356x

PATCH Superseded Frank Wunderlich 4 participants 14 messages Feb 27, 2022 – Feb 28, 2022

Subsystems (3)
Device tree bindings libata Arm Rockchip

v3 of 6 Superseded Latest is v6 →

lore
Share & tools
lore

Frank Wunderlich

author
#0 lore raw

v3 cover Add sata nodes to rk356x

From: Frank Wunderlich <[email protected]>

This Series converts the binding for ahci-platform to yaml and adds sata nodes to rockchip rk356x device trees.

v3:
- add conversion to sata-series
- fix some errors in dt_binding_check and dtbs_check
- move to unevaluated properties = false
- add power-domain to yaml
- move sata0 to rk3568.dtsi
- drop clock-names and interrupt-names

Frank Wunderlich (3):
dt-bindings: Convert ahci-platform DT bindings to yaml
dt-bindings: Add power-domains property to ahci-platform
arm64: dts: rockchip: Add sata nodes to rk356x

 .../devicetree/bindings/ata/ahci-platform.txt |  79 ----------
 .../bindings/ata/ahci-platform.yaml           | 143 ++++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3568.dtsi      |  14 ++
 arch/arm64/boot/dts/rockchip/rk356x.dtsi      |  26 ++++
 4 files changed, 183 insertions(+), 79 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/ata/ahci-platform.txt
 create mode 100644 Documentation/devicetree/bindings/ata/ahci-platform.yaml
Signature · 1 line
2.25.1
author
#1 lore raw

PATCH v3 1/3 dt-bindings: Convert ahci-platform DT bindings to yaml

From: Frank Wunderlich <[email protected]>

Create a yaml file for dtbs_check from the old txt binding.

Signed-off-by Frank Wunderlich <[email protected]>

---
v3:
- add conversion to sata-series
- fix some errors in dt_binding_check and dtbs_check
- move to unevaluated properties = false

---

imho all errors should be fixed in the dts not in the yaml...

errors about the subitem requirement that was defined in txt but not fixed some marvell dts

some dts for Marvell SoC bring error
'phys' is a required property
'target-supply' is a required property

problem is in arch/arm64/boot/dts/marvell/armada-cp11x.dtsi:331
here the sata-port@0 is defined, but not overridden with phy/target-supply in any following dts

====================================================================

arch/arm64/boot/dts/broadcom/northstar2 ns2-svk.dt.yaml:
ns2-xmc.dt.yaml:
ahci@663f2000:
$nodename:0: 'ahci@663f2000' does not match '^sata(@.*)?$'

Unevaluated properties are not allowed ('reg-names', '#address-cells', '#size-cells' were unexpected)

---
 .../devicetree/bindings/ata/ahci-platform.txt |  79 ----------
 .../bindings/ata/ahci-platform.yaml           | 140 ++++++++++++++++++
 2 files changed, 140 insertions(+), 79 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/ata/ahci-platform.txt
 create mode 100644 Documentation/devicetree/bindings/ata/ahci-platform.yaml
Documentation/devicetree/bindings/ata/ahci-platform.txt deleted +0 -79
deleted file mode 100644
index 77091a277642..000000000000
@@ -1,79 +0,0 @@
-* AHCI SATA Controller
-
-SATA nodes are defined to describe on-chip Serial ATA controllers.
-Each SATA controller should have its own node.
-
-It is possible, but not required, to represent each port as a sub-node.
-It allows to enable each port independently when dealing with multiple
-PHYs.
-
-Required properties:
-- compatible        : compatible string, one of:
-  - "brcm,iproc-ahci"
-  - "hisilicon,hisi-ahci"
-  - "cavium,octeon-7130-ahci"
-  - "ibm,476gtr-ahci"
-  - "marvell,armada-380-ahci"
-  - "marvell,armada-3700-ahci"
-  - "snps,dwc-ahci"
-  - "snps,spear-ahci"
-  - "generic-ahci"
-- interrupts        : <interrupt mapping for SATA IRQ>
-- reg               : <registers mapping>
-
-Please note that when using "generic-ahci" you must also specify a SoC specific
-compatible:
-	compatible = "manufacturer,soc-model-ahci", "generic-ahci";
-
-Optional properties:
-- dma-coherent      : Present if dma operations are coherent
-- clocks            : a list of phandle + clock specifier pairs
-- resets            : a list of phandle + reset specifier pairs
-- target-supply     : regulator for SATA target power
-- phy-supply        : regulator for PHY power
-- phys              : reference to the SATA PHY node
-- phy-names         : must be "sata-phy"
-- ahci-supply       : regulator for AHCI controller
-- ports-implemented : Mask that indicates which ports that the HBA supports
-		      are available for software to use. Useful if PORTS_IMPL
-		      is not programmed by the BIOS, which is true with
-		      some embedded SOC's.
-
-Required properties when using sub-nodes:
-- #address-cells    : number of cells to encode an address
-- #size-cells       : number of cells representing the size of an address
-
-Sub-nodes required properties:
-- reg		    : the port number
-And at least one of the following properties:
-- phys		    : reference to the SATA PHY node
-- target-supply     : regulator for SATA target power
-
-Examples:
-        sata@ffe08000 {
-		compatible = "snps,spear-ahci";
-		reg = <0xffe08000 0x1000>;
-		interrupts = <115>;
-        };
-
-With sub-nodes:
-	sata@f7e90000 {
-		compatible = "marvell,berlin2q-achi", "generic-ahci";
-		reg = <0xe90000 0x1000>;
-		interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&chip CLKID_SATA>;
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		sata0: sata-port@0 {
-			reg = <0>;
-			phys = <&sata_phy 0>;
-			target-supply = <&reg_sata0>;
-		};
-
-		sata1: sata-port@1 {
-			reg = <1>;
-			phys = <&sata_phy 1>;
-			target-supply = <&reg_sata1>;;
-		};
-	};
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +140 -0

140 lines not on this page · raw message

Signature · 1 line
2.25.1
#2 lore raw

Re: [PATCH v3 1/3] dt-bindings: Convert ahci-platform DT bindings to yaml

Quoted 10 lines · Frank Wunderlich

From: Frank Wunderlich <[email protected]>

Create a yaml file for dtbs_check from the old txt binding.

Signed-off-by Frank Wunderlich <[email protected]>

---
v3:
- add conversion to sata-series
- fix some errors in dt_binding_check and dtbs_check
- move to unevaluated properties = false

You missed devicetree mailing list (corrupted address).

Quoted 142 lines

---

imho all errors should be fixed in the dts not in the yaml...

errors about the subitem requirement that was defined in txt but not fixed some marvell dts

some dts for Marvell SoC bring error
'phys' is a required property
'target-supply' is a required property

problem is in arch/arm64/boot/dts/marvell/armada-cp11x.dtsi:331
here the sata-port@0 is defined, but not overridden with phy/target-supply in any following dts

====================================================================

arch/arm64/boot/dts/broadcom/northstar2 ns2-svk.dt.yaml:
ns2-xmc.dt.yaml:
ahci@663f2000:
$nodename:0: 'ahci@663f2000' does not match '^sata(@.*)?$'

Unevaluated properties are not allowed ('reg-names', '#address-cells', '#size-cells' were unexpected)

---
 .../devicetree/bindings/ata/ahci-platform.txt |  79 ----------
 .../bindings/ata/ahci-platform.yaml           | 140 ++++++++++++++++++
 2 files changed, 140 insertions(+), 79 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/ata/ahci-platform.txt
 create mode 100644 Documentation/devicetree/bindings/ata/ahci-platform.yaml
Documentation/devicetree/bindings/ata/ahci-platform.txt deleted +0 -79
deleted file mode 100644
index 77091a277642..000000000000
@@ -1,79 +0,0 @@
-* AHCI SATA Controller
-
-SATA nodes are defined to describe on-chip Serial ATA controllers.
-Each SATA controller should have its own node.
-
-It is possible, but not required, to represent each port as a sub-node.
-It allows to enable each port independently when dealing with multiple
-PHYs.
-
-Required properties:
-- compatible        : compatible string, one of:
-  - "brcm,iproc-ahci"
-  - "hisilicon,hisi-ahci"
-  - "cavium,octeon-7130-ahci"
-  - "ibm,476gtr-ahci"
-  - "marvell,armada-380-ahci"
-  - "marvell,armada-3700-ahci"
-  - "snps,dwc-ahci"
-  - "snps,spear-ahci"
-  - "generic-ahci"
-- interrupts        : <interrupt mapping for SATA IRQ>
-- reg               : <registers mapping>
-
-Please note that when using "generic-ahci" you must also specify a SoC specific
-compatible:
-	compatible = "manufacturer,soc-model-ahci", "generic-ahci";
-
-Optional properties:
-- dma-coherent      : Present if dma operations are coherent
-- clocks            : a list of phandle + clock specifier pairs
-- resets            : a list of phandle + reset specifier pairs
-- target-supply     : regulator for SATA target power
-- phy-supply        : regulator for PHY power
-- phys              : reference to the SATA PHY node
-- phy-names         : must be "sata-phy"
-- ahci-supply       : regulator for AHCI controller
-- ports-implemented : Mask that indicates which ports that the HBA supports
-		      are available for software to use. Useful if PORTS_IMPL
-		      is not programmed by the BIOS, which is true with
-		      some embedded SOC's.
-
-Required properties when using sub-nodes:
-- #address-cells    : number of cells to encode an address
-- #size-cells       : number of cells representing the size of an address
-
-Sub-nodes required properties:
-- reg		    : the port number
-And at least one of the following properties:
-- phys		    : reference to the SATA PHY node
-- target-supply     : regulator for SATA target power
-
-Examples:
-        sata@ffe08000 {
-		compatible = "snps,spear-ahci";
-		reg = <0xffe08000 0x1000>;
-		interrupts = <115>;
-        };
-
-With sub-nodes:
-	sata@f7e90000 {
-		compatible = "marvell,berlin2q-achi", "generic-ahci";
-		reg = <0xe90000 0x1000>;
-		interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&chip CLKID_SATA>;
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		sata0: sata-port@0 {
-			reg = <0>;
-			phys = <&sata_phy 0>;
-			target-supply = <&reg_sata0>;
-		};
-
-		sata1: sata-port@1 {
-			reg = <1>;
-			phys = <&sata_phy 1>;
-			target-supply = <&reg_sata1>;;
-		};
-	};
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +20 -0
new file mode 100644
index 000000000000..cc246b312c59
@@ -0,0 +1,140 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/ahci-platform.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AHCI SATA Controller
+description:
+  SATA nodes are defined to describe on-chip Serial ATA controllers.
+  Each SATA controller should have its own node.
+
+  It is possible, but not required, to represent each port as a sub-node.
+  It allows to enable each port independently when dealing with multiple
+  PHYs.
+
+maintainers:
+  - Hans de Goede <[email protected]>
+  - Jens Axboe <[email protected]>
+
+properties:

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 30

Quoted 10 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +10 -0
+  compatible:
+    contains:
+      enum:
+        - brcm,iproc-ahci
+        - cavium,octeon-7130-ahci
+        - generic-ahci
+        - hisilicon,hisi-ahci
+        - ibm,476gtr-ahci
+        - marvell,armada-380-ahci
+        - marvell,armada-3700-ahci

Order entries alphabetically.

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 32

Quoted 2 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +2 -0
+        - snps,dwc-ahci
+        - snps,spear-ahci

You converted the TXT bindings explicitly, but you missed the comment just below the 'reg' about generic-ahci. The generic-ahci never comes alone.

The snps,dwc-ahci could come, although history shows that Synapsys blocks are commonly re-used and they should have specific compatible. Current users still have single snps,dwc-ahci, so it could be fixed a bit later.

On the other hand, I expect to fix all the DTS in the same series where the bindings are corrected.

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 39

Quoted 7 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +7 -0
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    minItems: 1
+    maxItems: 3

Items should be described. Next or this patch could add also clock-names.

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 42

Quoted 3 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +3 -0
+
+  interrupts:
+    minItems: 1

You mean maxItems?

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 50

Quoted 8 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +8 -0
+
+  ahci-supply:
+    description:
+      regulator for AHCI controller
+
+  dma-coherent:
+    description:
+      Present if dma operations are coherent

Skip description, it's obvious. Just 'true'.

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 57

Quoted 7 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +7 -0
+
+  phy-supply:
+    description:
+      regulator for PHY power
+
+  phys:
+    minItems: 1

maxItems?

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 60

Quoted 3 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +3 -0
+
+  phy-names:
+    minItems: 1

Describe the items.

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 68

Quoted 8 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +8 -0
+
+  ports-implemented:
+    description:
+      Mask that indicates which ports that the HBA supports
+      are available for software to use. Useful if PORTS_IMPL
+      is not programmed by the BIOS, which is true with
+      some embedded SoCs.
+    minItems: 1

You need a type and maxItems.

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 71

Quoted 3 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +3 -0
+
+  resets:
+    minItems: 1

maxItems?

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 83

Quoted 12 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +12 -0
+
+  target-supply:
+    description:
+      regulator for SATA target power
+
+required:
+  - compatible
+  - reg
+  - interrupts
+
+patternProperties:
+  "^sata-port@[0-9]+$":

You limit number of ports to 10. On purpose? What about 0xa? 0xb?

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 93

Quoted 10 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +10 -0
+    type: object
+    description:
+      Subnode with configuration of the Ports.
+
+    properties:
+      reg:
+        maxItems: 1
+
+      phys:
+        minItems: 1

maxItems? Why do you put everywhere minItems? Are several phys really expected?

Quoted 4 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +4 -0
+
+      target-supply:
+        description:
+          regulator for SATA target power

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 107

Quoted 10 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +10 -0
+
+    required:
+      - reg
+
+    anyOf:
+      - required: [ phys ]
+      - required: [ target-supply ]
+
+allOf:
+- $ref: "sata-common.yaml#"

This goes before properties.

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 113

Quoted 6 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +6 -0
+
+unevaluatedProperties: false
+
+examples:
+  - |
+        sata@ffe08000 {

Wrong indentation. It starts just below |

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 122

Quoted 9 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +9 -0
+               compatible = "snps,spear-ahci";
+               reg = <0xffe08000 0x1000>;
+               interrupts = <115>;
+        };
+  - |
+        #include <dt-bindings/interrupt-controller/arm-gic.h>
+        #include <dt-bindings/clock/berlin2q.h>
+        sata@f7e90000 {
+                compatible = "marvell,berlin2q-achi", "generic-ahci";

This clearly won't pass your checks. I don't think you run dt_binding_check. You must test your bindings first.

Quoted 8 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +8 -0
+                reg = <0xe90000 0x1000>;
+                interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+                clocks = <&chip CLKID_SATA>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                sata0: sata-port@0 {
+                        reg = <0>;

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 140

Quoted 10 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +10 -0
+                        phys = <&sata_phy 0>;
+                        target-supply = <&reg_sata0>;
+                };
+
+                sata1: sata-port@1 {
+                        reg = <1>;
+                        phys = <&sata_phy 1>;
+                        target-supply = <&reg_sata1>;
+                };
+        };

Best regards,
Krzysztof

#3 lore raw

Aw: Re: [PATCH v3 1/3] dt-bindings: Convert ahci-platform DT bindings to yaml

Hi Krzysztof,

thanks for first review.

Quoted 7 lines

Gesendet: Montag, 28. Februar 2022 um 11:08 Uhr
Von: "Krzysztof Kozlowski" <[email protected]>

Quoted 1 line · Frank Wunderlich

From: Frank Wunderlich <[email protected]>

You missed devicetree mailing list (corrupted address).

sorry, devicetree ML was To, but forget the Cc-Header (prepared addresses in coverletter)

Quoted 7 lines
Quoted 7 lines

imho all errors should be fixed in the dts not in the yaml...

-- reg : <registers mapping>

Documentation/devicetree/bindings/ata/ahci-platform.txt deleted +0 -4
-
-Please note that when using "generic-ahci" you must also specify a SoC specific
-compatible:
-	compatible = "manufacturer,soc-model-ahci", "generic-ahci";

...

Quoted 12 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 30

Quoted 11 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +11 -0
+properties:
+  compatible:
+    contains:
+      enum:
+        - brcm,iproc-ahci
+        - cavium,octeon-7130-ahci
+        - generic-ahci
+        - hisilicon,hisi-ahci
+        - ibm,476gtr-ahci
+        - marvell,armada-380-ahci
+        - marvell,armada-3700-ahci
Quoted 1 line

Order entries alphabetically.

ok

Quoted 5 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 32

Quoted 2 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +2 -0
+        - snps,dwc-ahci
+        - snps,spear-ahci

You converted the TXT bindings explicitly, but you missed the comment just below the 'reg' about generic-ahci. The generic-ahci never comes alone.

How should this comment be added? description above/below the compatible-property? Sorry for dumb questions...this is my first yaml ;)

e.g.

properties:
compatible:
description:
Please note that when using "generic-ahci" you must also specify a SoC specific compatible:
compatible = "manufacturer,soc-model-ahci", "generic-ahci";
contains:
enum:

Quoted 7 lines

The snps,dwc-ahci could come, although history shows that Synapsys blocks are commonly re-used and they should have specific compatible. Current users still have single snps,dwc-ahci, so it could be fixed a bit later.

On the other hand, I expect to fix all the DTS in the same series where the bindings are corrected.

i don't know the marvell/broadcom-hw so i cannot fix them. Just converted the txt to check my rockchip sata nodes and to be more future-proof (no more exceptions like the marvell/broadcom)

Quoted 9 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 39

Quoted 7 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +7 -0
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    minItems: 1
+    maxItems: 3

Items should be described. Next or this patch could add also clock-names.

i was told to drop clock-names (same for interrupt-names and reset-names) from dts and in txt it was not there so have not added it

https://patchwork.kernel.org/comment/24755956/

Quoted 5 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 42

Quoted 3 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +3 -0
+
+  interrupts:
+    minItems: 1

You mean maxItems?

no, minItems, as interrupts suggests 1+ (same for phys)

Quoted 10 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 50

Quoted 8 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +8 -0
+
+  ahci-supply:
+    description:
+      regulator for AHCI controller
+
+  dma-coherent:
+    description:
+      Present if dma operations are coherent

Skip description, it's obvious. Just 'true'.

ok, took this from the txt

Quoted 24 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 57

Quoted 7 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +7 -0
+
+  phy-supply:
+    description:
+      regulator for PHY power
+
+  phys:
+    minItems: 1

maxItems?

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 60

Quoted 3 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +3 -0
+
+  phy-names:
+    minItems: 1

Describe the items.

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 68

Quoted 8 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +8 -0
+
+  ports-implemented:
+    description:
+      Mask that indicates which ports that the HBA supports
+      are available for software to use. Useful if PORTS_IMPL
+      is not programmed by the BIOS, which is true with
+      some embedded SoCs.
+    minItems: 1
Quoted 1 line

You need a type and maxItems.

what will be the type of a mask?

Quoted 5 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 71

Quoted 3 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +3 -0
+
+  resets:
+    minItems: 1

maxItems?

if there is a known maximum....

Quoted 6 lines
Quoted 6 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +6 -0
+
+  target-supply:
+    description:
+      regulator for SATA target power
+
+required:
Quoted 8 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 83

Quoted 6 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +6 -0
+  - compatible
+  - reg
+  - interrupts
+
+patternProperties:
+  "^sata-port@[0-9]+$":

You limit number of ports to 10. On purpose? What about 0xa? 0xb?

oh, right, there can be hexadecimal...
thought this is only true for the main-node (address) and have only seen @0, @1 and @2

Quoted 5 lines
Quoted 5 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +5 -0
+    type: object
+    description:
+      Subnode with configuration of the Ports.
+
+    properties:
Quoted 8 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 57

Quoted 5 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +5 -0
+      reg:
+        maxItems: 1
+
+      phys:
+        minItems: 1

maxItems? Why do you put everywhere minItems? Are several phys really expected?

name suggests that it can be more than 1. i know from usb subsystem (dwc3 usb3) that a device can have more than one phy, and because in the txt there are no ranges i set everywhere MinItems to 1 with open end as i do not know all possibilities. Anything else will be trial and error...for all properties

Quoted 17 lines
Quoted 4 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +4 -0
+
+      target-supply:
+        description:
+          regulator for SATA target power

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 107

Quoted 10 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +10 -0
+
+    required:
+      - reg
+
+    anyOf:
+      - required: [ phys ]
+      - required: [ target-supply ]
+
+allOf:
+- $ref: "sata-common.yaml#"

This goes before properties.

Quoted 8 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 113

Quoted 6 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +6 -0
+
+unevaluatedProperties: false
+
+examples:
+  - |
+        sata@ffe08000 {

Wrong indentation. It starts just below |

will fix it

Quoted 10 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 122

Quoted 9 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +9 -0
+               compatible = "snps,spear-ahci";
+               reg = <0xffe08000 0x1000>;
+               interrupts = <115>;
+        };
+  - |
+        #include <dt-bindings/interrupt-controller/arm-gic.h>
+        #include <dt-bindings/clock/berlin2q.h>
+        sata@f7e90000 {
+                compatible = "marvell,berlin2q-achi", "generic-ahci";
Quoted 2 lines

This clearly won't pass your checks. I don't think you run dt_binding_check. You must test your bindings first.

i had them tested ...needed to add the includes...after that the dt_bindings_check was without errors/warnings

these are the commands i used:

ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ata/ahci-platform.yaml ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ata/ahci-platform.yaml

Quoted 2 lines

Best regards,
Krzysztof

regards Frank

#4 lore raw

Re: Aw: Re: [PATCH v3 1/3] dt-bindings: Convert ahci-platform DT bindings to yaml

Quoted 38 lines · Frank Wunderlich

Hi Krzysztof,

thanks for first review.

Quoted 7 lines

Gesendet: Montag, 28. Februar 2022 um 11:08 Uhr
Von: "Krzysztof Kozlowski" <[email protected]>

Quoted 1 line · Frank Wunderlich

From: Frank Wunderlich <[email protected]>

You missed devicetree mailing list (corrupted address).

sorry, devicetree ML was To, but forget the Cc-Header (prepared addresses in coverletter)

Quoted 7 lines
Quoted 7 lines

imho all errors should be fixed in the dts not in the yaml...

-- reg : <registers mapping>

Documentation/devicetree/bindings/ata/ahci-platform.txt deleted +0 -4
-
-Please note that when using "generic-ahci" you must also specify a SoC specific
-compatible:
-	compatible = "manufacturer,soc-model-ahci", "generic-ahci";

...

Quoted 12 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 30

Quoted 11 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +11 -0
+properties:
+  compatible:
+    contains:
+      enum:
+        - brcm,iproc-ahci
+        - cavium,octeon-7130-ahci
+        - generic-ahci
+        - hisilicon,hisi-ahci
+        - ibm,476gtr-ahci
+        - marvell,armada-380-ahci
+        - marvell,armada-3700-ahci
Quoted 1 line

Order entries alphabetically.

ok

Quoted 8 lines
Quoted 5 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 32

Quoted 2 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +2 -0
+        - snps,dwc-ahci
+        - snps,spear-ahci

You converted the TXT bindings explicitly, but you missed the comment just below the 'reg' about generic-ahci. The generic-ahci never comes alone.

How should this comment be added? description above/below the compatible-property? Sorry for dumb questions...this is my first yaml ;)

No, this has to be oneOf. See for example Documentation/devicetree/bindings/gpio/gpio-vf610.yaml or many other files.

Quoted 34 lines

e.g.

properties:
compatible:
description:
Please note that when using "generic-ahci" you must also specify a SoC specific compatible:
compatible = "manufacturer,soc-model-ahci", "generic-ahci";
contains:
enum:

Quoted 7 lines

The snps,dwc-ahci could come, although history shows that Synapsys blocks are commonly re-used and they should have specific compatible. Current users still have single snps,dwc-ahci, so it could be fixed a bit later.

On the other hand, I expect to fix all the DTS in the same series where the bindings are corrected.

i don't know the marvell/broadcom-hw so i cannot fix them. Just converted the txt to check my rockchip sata nodes and to be more future-proof (no more exceptions like the marvell/broadcom)

Quoted 9 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 39

Quoted 7 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +7 -0
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    minItems: 1
+    maxItems: 3

Items should be described. Next or this patch could add also clock-names.

Quoted 4 lines

i was told to drop clock-names (same for interrupt-names and reset-names) from dts and in txt it was not there so have not added it

https://patchwork.kernel.org/comment/24755956/

OK, then let's skip them now. The clock items should be described if it is possible.

Quoted 8 lines
Quoted 6 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 42

Quoted 4 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +3 -0
+
+  interrupts:
+    minItems: 1

You mean maxItems?

no, minItems, as interrupts suggests 1+ (same for phys)

You cannot have infinite number of interrupts... What suggests "1+"? What does it mean "as interrupts suggests"? Do these hardware blocks really have many interrupt lines?

The same for phys.

Quoted 38 lines
Quoted 11 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 50

Quoted 9 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +8 -0
+
+  ahci-supply:
+    description:
+      regulator for AHCI controller
+
+  dma-coherent:
+    description:
+      Present if dma operations are coherent

Skip description, it's obvious. Just 'true'.

ok, took this from the txt

Quoted 24 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 57

Quoted 7 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +7 -0
+
+  phy-supply:
+    description:
+      regulator for PHY power
+
+  phys:
+    minItems: 1

maxItems?

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 60

Quoted 3 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +3 -0
+
+  phy-names:
+    minItems: 1

Describe the items.

Quoted 8 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +8 -0
+
+  ports-implemented:
+    description:
+      Mask that indicates which ports that the HBA supports
+      are available for software to use. Useful if PORTS_IMPL
+      is not programmed by the BIOS, which is true with
+      some embedded SoCs.
+    minItems: 1
Quoted 3 lines
Quoted 1 line

You need a type and maxItems.

what will be the type of a mask?

git grep ports-implemented gives pretty straightfoward answer. All DTS have u32 and driver also uses u32.

Quoted 8 lines
Quoted 6 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 71

Quoted 4 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +3 -0
+
+  resets:
+    minItems: 1

maxItems?

if there is a known maximum....

Must be. You cannot have infinite number of reset lines... Please check all DTS and drivers. If there is public documentation, it also might be useful.

Quoted 33 lines
Quoted 15 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 83

Quoted 13 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +12 -0
+
+  target-supply:
+    description:
+      regulator for SATA target power
+
+required:
+  - compatible
+  - reg
+  - interrupts
+
+patternProperties:
+  "^sata-port@[0-9]+$":

You limit number of ports to 10. On purpose? What about 0xa? 0xb?

oh, right, there can be hexadecimal...
thought this is only true for the main-node (address) and have only seen @0, @1 and @2

Quoted 5 lines
Quoted 5 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +5 -0
+    type: object
+    description:
+      Subnode with configuration of the Ports.
+
+    properties:
Quoted 8 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 57

Quoted 5 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +5 -0
+      reg:
+        maxItems: 1
+
+      phys:
+        minItems: 1

maxItems? Why do you put everywhere minItems? Are several phys really expected?

Quoted 1 line

name suggests that it can be more than 1.

What do you mean "name suggests"? Name of property? No, it does not suggest that. Name is standard. Please check example schema and other existing schema bindings to see how it is done. For example earlier gpio-vf610.yaml is not bad.

Quoted 1 line

i know from usb subsystem (dwc3 usb3) that a device can have more than one phy, and because in the txt there are no ranges i set everywhere MinItems to 1 with open end as i do not know all possibilities. Anything else will be trial and error...for all properties

The bindings need to be specific, so only properties which really, really can have many unknown elements we could keep here some high maxItems limit. In 99% of cases maxItems are clearly defined.

Quoted 42 lines
Quoted 18 lines
Quoted 5 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +4 -0
+
+      target-supply:
+        description:
+          regulator for SATA target power

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 107

Quoted 10 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +10 -0
+
+    required:
+      - reg
+
+    anyOf:
+      - required: [ phys ]
+      - required: [ target-supply ]
+
+allOf:
+- $ref: "sata-common.yaml#"

This goes before properties.

Quoted 8 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 113

Quoted 6 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +6 -0
+
+unevaluatedProperties: false
+
+examples:
+  - |
+        sata@ffe08000 {

Wrong indentation. It starts just below |

will fix it

Quoted 10 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 122

Quoted 9 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +9 -0
+               compatible = "snps,spear-ahci";
+               reg = <0xffe08000 0x1000>;
+               interrupts = <115>;
+        };
+  - |
+        #include <dt-bindings/interrupt-controller/arm-gic.h>
+        #include <dt-bindings/clock/berlin2q.h>
+        sata@f7e90000 {
+                compatible = "marvell,berlin2q-achi", "generic-ahci";
Quoted 2 lines

This clearly won't pass your checks. I don't think you run dt_binding_check. You must test your bindings first.

Quoted 6 lines

i had them tested ...needed to add the includes...after that the dt_bindings_check was without errors/warnings

these are the commands i used:

ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ata/ahci-platform.yaml ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ata/ahci-platform.yaml

Install dependencies (libyaml-dev) and you will see first error:
Documentation/devicetree/bindings/ata/ahci-platform.yaml:110:1:
[warning] wrong indentation: expected 2 but found 0 (indentation)

But the one I am thinking is indeed not visible by default. You would need to run it like Rob's boot is running, so add DT_CHECKER_FLAGS=-m. Then you see:

Documentation/devicetree/bindings/ata/ahci-platform.example.dt.yaml:0:0:
/example-1/sata@f7e90000: failed to match any schema with compatible:
['marvell,berlin2q-achi', 'generic-ahci']

Best regards,
Krzysztof

#5 lore raw

Aw: Re: Re: [PATCH v3 1/3] dt-bindings: Convert ahci-platform DT bindings to yaml

Hi,

looks like i'm not the right person to convert the binding. I have not enough knowledge about yaml, bindings, drivers, ...

i will try you suggestions for me as a lerning-by-doing approach, but will drop it from the series, same for part2 as it depends on first.

Quoted 5 lines

Gesendet: Montag, 28. Februar 2022 um 13:38 Uhr
Von: "Krzysztof Kozlowski" <[email protected]>

On 28/02/2022 13:19, Frank Wunderlich wrote:

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

You converted the TXT bindings explicitly, but you missed the comment just below the 'reg' about generic-ahci. The generic-ahci never comes alone.

How should this comment be added? description above/below the compatible-property? Sorry for dumb questions...this is my first yaml ;)

No, this has to be oneOf. See for example Documentation/devicetree/bindings/gpio/gpio-vf610.yaml or many other files.

Afaik the generic-ahci should be defined optional with one of the others needed, but afaik this will duplicate the list i had.

so i end up in a struct like this

compatible:
oneOf:
- enum:
- brcm,iproc-ahci
- cavium,octeon-7130-ahci
- hisilicon,hisi-ahci
- ibm,476gtr-ahci
- marvell,armada-3700-ahci
- marvell,armada-380-ahci
- snps,dwc-ahci
- snps,spear-ahci
- items:
- const: generic-ahci
- enum:
- brcm,iproc-ahci
- cavium,octeon-7130-ahci
- hisilicon,hisi-ahci
- ibm,476gtr-ahci
- marvell,armada-3700-ahci
- marvell,armada-380-ahci
- snps,dwc-ahci
- snps,spear-ahci

Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
Quoted 2 lines

+ interrupts:
+ minItems: 1

You mean maxItems?

Quoted 7 lines
Quoted 1 line

no, minItems, as interrupts suggests 1+ (same for phys)

You cannot have infinite number of interrupts... What suggests "1+"? What does it mean "as interrupts suggests"? Do these hardware blocks really have many interrupt lines?

The same for phys.

interrupts/phys is plural of interrupt/phy, so it suggests it can be more than 1.

as i said i do not know every driver with all possibilities, so i started with the min-items as we need at least 1 interrupt/phy, but yes if there are any limits then they should be added, but this needs extensive knowledge about the drivers/hardware, i don't have.

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines

+ ports-implemented:
+ description:
+ Mask that indicates which ports that the HBA supports
+ are available for software to use. Useful if PORTS_IMPL
+ is not programmed by the BIOS, which is true with
+ some embedded SoCs.
+ minItems: 1

Quoted 6 lines
Quoted 3 lines
Quoted 1 line

You need a type and maxItems.

what will be the type of a mask?

git grep ports-implemented gives pretty straightfoward answer. All DTS have u32 and driver also uses u32.

so type should be

$ref: '/schemas/types.yaml#/definitions/uint32'

?

it's the only one i've found with u32 looking like a type

found in Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines

+
+ resets:
+ minItems: 1

Quoted 7 lines
Quoted 3 lines
Quoted 1 line

maxItems?

if there is a known maximum....

Must be. You cannot have infinite number of reset lines... Please check all DTS and drivers. If there is public documentation, it also might be useful.

"Please check all DTS and drivers." this is impossible for me as doing this as hobby with still limited time ;(

Quoted 40 lines
Quoted 33 lines
Quoted 15 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 83

Quoted 13 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +12 -0
+
+ target-supply:
+ description:
+ regulator for SATA target power
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+patternProperties:
+ "^sata-port@[0-9]+$":

You limit number of ports to 10. On purpose? What about 0xa? 0xb?

oh, right, there can be hexadecimal...
thought this is only true for the main-node (address) and have only seen @0, @1 and @2

Quoted 5 lines
Quoted 5 lines

+ type: object
+ description:
+ Subnode with configuration of the Ports.
+
+ properties:

Quoted 8 lines
Quoted 5 lines

+ reg:
+ maxItems: 1
+
+ phys:
+ minItems: 1

maxItems? Why do you put everywhere minItems? Are several phys really expected?

Quoted 1 line

name suggests that it can be more than 1.

What do you mean "name suggests"? Name of property? No, it does not suggest that. Name is standard. Please check example schema and other existing schema bindings to see how it is done. For example earlier gpio-vf610.yaml is not bad.

Quoted 5 lines
Quoted 1 line

i know from usb subsystem (dwc3 usb3) that a device can have more than one phy, and because in the txt there are no ranges i set everywhere MinItems to 1 with open end as i do not know all possibilities. Anything else will be trial and error...for all properties

The bindings need to be specific, so only properties which really, really can have many unknown elements we could keep here some high maxItems limit. In 99% of cases maxItems are clearly defined.

so i need to do try-and-error, setting maxItems to 1, make checks, if failing look in driver, increase, ...

but this is maybe not the right way to do as dts can contain errors which should not modify the binding.

Quoted 9 lines
Quoted 4 lines

these are the commands i used:

ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ata/ahci-platform.yaml ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ata/ahci-platform.yaml

Install dependencies (libyaml-dev) and you will see first error:
Documentation/devicetree/bindings/ata/ahci-platform.yaml:110:1:
[warning] wrong indentation: expected 2 but found 0 (indentation)

Quoted 7 lines

But the one I am thinking is indeed not visible by default. You would need to run it like Rob's boot is running, so add DT_CHECKER_FLAGS=-m. Then you see:

Documentation/devicetree/bindings/ata/ahci-platform.example.dt.yaml:0:0:
/example-1/sata@f7e90000: failed to match any schema with compatible:
['marvell,berlin2q-achi', 'generic-ahci']

i try this, but imho it's better to drop the Patch as i'm no expert in this, don't know the HW/drivers enough and this will delay the dts patch too much. I thought i can help getting this (simple looking) txt converted to yaml.
Seems the binding needs to be done by someone who knows the drivers more than me.

regards Frank

#6 lore raw

Re: Aw: Re: Re: [PATCH v3 1/3] dt-bindings: Convert ahci-platform DT bindings to yaml

Quoted 40 lines · Frank Wunderlich

Hi,

looks like i'm not the right person to convert the binding. I have not enough knowledge about yaml, bindings, drivers, ...

i will try you suggestions for me as a lerning-by-doing approach, but will drop it from the series, same for part2 as it depends on first.

Quoted 5 lines

Gesendet: Montag, 28. Februar 2022 um 13:38 Uhr
Von: "Krzysztof Kozlowski" <[email protected]>

On 28/02/2022 13:19, Frank Wunderlich wrote:

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

You converted the TXT bindings explicitly, but you missed the comment just below the 'reg' about generic-ahci. The generic-ahci never comes alone.

How should this comment be added? description above/below the compatible-property? Sorry for dumb questions...this is my first yaml ;)

No, this has to be oneOf. See for example Documentation/devicetree/bindings/gpio/gpio-vf610.yaml or many other files.

Afaik the generic-ahci should be defined optional with one of the others needed, but afaik this will duplicate the list i had.

so i end up in a struct like this

compatible:
oneOf:
- enum:
- brcm,iproc-ahci
- cavium,octeon-7130-ahci
- hisilicon,hisi-ahci
- ibm,476gtr-ahci
- marvell,armada-3700-ahci
- marvell,armada-380-ahci
- snps,dwc-ahci
- snps,spear-ahci
- items:
- const: generic-ahci
- enum:

Quoted 8 lines

- brcm,iproc-ahci
- cavium,octeon-7130-ahci
- hisilicon,hisi-ahci
- ibm,476gtr-ahci
- marvell,armada-3700-ahci
- marvell,armada-380-ahci
- snps,dwc-ahci
- snps,spear-ahci

That could be one way, but instead I propose to have only second part (so enum + generic-ahci) for all compatibles mentioned in ahci_platform.c, which do not customize the driver behavior for these compatibles..

Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines

+ interrupts:
+ minItems: 1

You mean maxItems?

no, minItems, as interrupts suggests 1+ (same for phys)

Quoted 7 lines
Quoted 5 lines

You cannot have infinite number of interrupts... What suggests "1+"? What does it mean "as interrupts suggests"? Do these hardware blocks really have many interrupt lines?

The same for phys.

interrupts/phys is plural of interrupt/phy, so it suggests it can be more than 1.

There is no property named "interrupt" or "phy". There is only "interrupts", "phys", "gpios", "clocks" etc. regardless whether there is one or multiple items. This is not specific to bindings, but all DTS have this.

Quoted 2 lines

as i said i do not know every driver with all possibilities, so i started with the min-items as we need at least 1 interrupt/phy, but yes if there are any limits then they should be added, but this needs extensive knowledge about the drivers/hardware, i don't have.

But the sources of the driver and DTS are available, why not using them?

Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 10 lines
Quoted 8 lines

+ ports-implemented:
+ description:
+ Mask that indicates which ports that the HBA supports
+ are available for software to use. Useful if PORTS_IMPL
+ is not programmed by the BIOS, which is true with
+ some embedded SoCs.
+ minItems: 1

You need a type and maxItems.

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

what will be the type of a mask?

git grep ports-implemented gives pretty straightfoward answer. All DTS have u32 and driver also uses u32.

so type should be

$ref: '/schemas/types.yaml#/definitions/uint32'

Yes. See example schema.

Quoted 6 lines

?

it's the only one i've found with u32 looking like a type

found in Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml

This part I do not understand.

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 5 lines

+
+ resets:
+ minItems: 1

maxItems?

Quoted 7 lines
Quoted 5 lines
Quoted 1 line

if there is a known maximum....

Must be. You cannot have infinite number of reset lines... Please check all DTS and drivers. If there is public documentation, it also might be useful.

"Please check all DTS and drivers." this is impossible for me as doing this as hobby with still limited time ;(

I believe that information - how many resets - is in general findable via driver sources. In all bindings conversions, if we do not have such information, we need to try to look it up.

Quoted 40 lines
Quoted 39 lines
Quoted 33 lines
Quoted 15 lines

Documentation/devicetree/bindings/ata/ahci-platform.yaml line 83

Quoted 13 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml new file +12 -0
+
+ target-supply:
+ description:
+ regulator for SATA target power
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+patternProperties:
+ "^sata-port@[0-9]+$":

You limit number of ports to 10. On purpose? What about 0xa? 0xb?

oh, right, there can be hexadecimal...
thought this is only true for the main-node (address) and have only seen @0, @1 and @2

Quoted 5 lines
Quoted 5 lines

+ type: object
+ description:
+ Subnode with configuration of the Ports.
+
+ properties:

Quoted 8 lines
Quoted 5 lines

+ reg:
+ maxItems: 1
+
+ phys:
+ minItems: 1

maxItems? Why do you put everywhere minItems? Are several phys really expected?

Quoted 1 line

name suggests that it can be more than 1.

What do you mean "name suggests"? Name of property? No, it does not suggest that. Name is standard. Please check example schema and other existing schema bindings to see how it is done. For example earlier gpio-vf610.yaml is not bad.

Quoted 7 lines
Quoted 5 lines
Quoted 1 line

i know from usb subsystem (dwc3 usb3) that a device can have more than one phy, and because in the txt there are no ranges i set everywhere MinItems to 1 with open end as i do not know all possibilities. Anything else will be trial and error...for all properties

The bindings need to be specific, so only properties which really, really can have many unknown elements we could keep here some high maxItems limit. In 99% of cases maxItems are clearly defined.

so i need to do try-and-error, setting maxItems to 1, make checks, if failing look in driver, increase, ...

Why try-and-error? "git grep" works here...

Quoted 2 lines

but this is maybe not the right way to do as dts can contain errors which should not modify the binding.

True, but having stricter limit, even if not fully correct, is better than having too loose limit. Stricter can be always loosened. Loose requirement cannot be made stricter.

Quoted 18 lines
Quoted 10 lines
Quoted 5 lines

these are the commands i used:

ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ata/ahci-platform.yaml ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ata/ahci-platform.yaml

Install dependencies (libyaml-dev) and you will see first error:
Documentation/devicetree/bindings/ata/ahci-platform.yaml:110:1:
[warning] wrong indentation: expected 2 but found 0 (indentation)

Quoted 7 lines

But the one I am thinking is indeed not visible by default. You would need to run it like Rob's boot is running, so add DT_CHECKER_FLAGS=-m. Then you see:

Documentation/devicetree/bindings/ata/ahci-platform.example.dt.yaml:0:0:
/example-1/sata@f7e90000: failed to match any schema with compatible:
['marvell,berlin2q-achi', 'generic-ahci']

Quoted 5 lines

i try this, but imho it's better to drop the Patch as i'm no expert in this, don't know the HW/drivers enough and this will delay the dts patch too much. I thought i can help getting this (simple looking) txt converted to yaml.
Seems the binding needs to be done by someone who knows the drivers more than me.

regards Frank

Best regards,
Krzysztof

#7 lore raw

Aw: Re: Re: Re: [PATCH v3 1/3] dt-bindings: Convert ahci-platform DT bindings to yaml

Hi

Quoted 31 lines

Gesendet: Montag, 28. Februar 2022 um 15:35 Uhr
Von: "Krzysztof Kozlowski" <[email protected]>

Quoted 20 lines
Quoted 5 lines

Gesendet: Montag, 28. Februar 2022 um 13:38 Uhr
Von: "Krzysztof Kozlowski" <[email protected]>

No, this has to be oneOf. See for example Documentation/devicetree/bindings/gpio/gpio-vf610.yaml or many other files.

compatible:
oneOf:
- enum:
- brcm,iproc-ahci
- cavium,octeon-7130-ahci
- hisilicon,hisi-ahci
- ibm,476gtr-ahci
- marvell,armada-3700-ahci
- marvell,armada-380-ahci
- snps,dwc-ahci
- snps,spear-ahci
- items:
- const: generic-ahci
- enum:

Quoted 8 lines

- brcm,iproc-ahci
- cavium,octeon-7130-ahci
- hisilicon,hisi-ahci
- ibm,476gtr-ahci
- marvell,armada-3700-ahci
- marvell,armada-380-ahci
- snps,dwc-ahci
- snps,spear-ahci

Quoted 4 lines

That could be one way, but instead I propose to have only second part (so enum + generic-ahci) for all compatibles mentioned in ahci_platform.c, which do not customize the driver behavior for these compatibles..

tried many ways of defining it, but none passes with the examples. either to short (first example) or too long (second)

as far as i understand the logic it should be similar to this:

properties:
compatible:
oneOf:
- items:
- enum:
- marvell,berlin2q-achi
- const: generic-ahci
- items:
- enum:
- brcm,iproc-ahci
- cavium,octeon-7130-ahci
- hisilicon,hisi-ahci
- ibm,476gtr-ahci
- marvell,armada-3700-ahci
- marvell,armada-380-ahci
- snps,dwc-ahci
- snps,spear-ahci

this passes the dt-binding_check (examples) for me, but i guess there are many more compatibles defined with the generic.

dtbs_check found some more like

'brcm,iproc-ahci'
'marvell,armada-8k-ahci'
and many more

it looks like these are also checked in the enum, so the yaml itself look correct, but needs some kind of wildcard instead of the "marvell,berlin2q-achi" as second for the generic-ahci compatible

regards Frank

#8 lore raw

Re: Aw: Re: Re: Re: [PATCH v3 1/3] dt-bindings: Convert ahci-platform DT bindings to yaml

Quoted 40 lines · Frank Wunderlich

Hi

Quoted 31 lines

Gesendet: Montag, 28. Februar 2022 um 15:35 Uhr
Von: "Krzysztof Kozlowski" <[email protected]>

Quoted 20 lines
Quoted 5 lines

Gesendet: Montag, 28. Februar 2022 um 13:38 Uhr
Von: "Krzysztof Kozlowski" <[email protected]>

No, this has to be oneOf. See for example Documentation/devicetree/bindings/gpio/gpio-vf610.yaml or many other files.

compatible:
oneOf:
- enum:
- brcm,iproc-ahci
- cavium,octeon-7130-ahci
- hisilicon,hisi-ahci
- ibm,476gtr-ahci
- marvell,armada-3700-ahci
- marvell,armada-380-ahci
- snps,dwc-ahci
- snps,spear-ahci
- items:
- const: generic-ahci
- enum:

Quoted 8 lines

- brcm,iproc-ahci
- cavium,octeon-7130-ahci
- hisilicon,hisi-ahci
- ibm,476gtr-ahci
- marvell,armada-3700-ahci
- marvell,armada-380-ahci
- snps,dwc-ahci
- snps,spear-ahci

Quoted 4 lines

That could be one way, but instead I propose to have only second part (so enum + generic-ahci) for all compatibles mentioned in ahci_platform.c, which do not customize the driver behavior for these compatibles..

tried many ways of defining it, but none passes with the examples. either to short (first example) or too long (second)

Quoted 8 lines

as far as i understand the logic it should be similar to this:

properties:
compatible:
oneOf:
- items:
- enum:
- marvell,berlin2q-achi

You need to extend this enum with all the entries I mentioned before.

Quoted 2 lines

- const: generic-ahci
- items:

No items here, directly enum.

Quoted 14 lines

- enum:
- brcm,iproc-ahci
- cavium,octeon-7130-ahci
- hisilicon,hisi-ahci
- ibm,476gtr-ahci
- marvell,armada-3700-ahci
- marvell,armada-380-ahci
- snps,dwc-ahci
- snps,spear-ahci

this passes the dt-binding_check (examples) for me, but i guess there are many more compatibles defined with the generic.

dtbs_check found some more like

Quoted 7 lines

'brcm,iproc-ahci'
'marvell,armada-8k-ahci'
and many more

it looks like these are also checked in the enum, so the yaml itself look correct, but needs some kind of wildcard instead of the "marvell,berlin2q-achi" as second for the generic-ahci compatible

regards Frank

Best regards,
Krzysztof

author
#9 lore raw

PATCH v3 2/3 dt-bindings: Add power-domains property to ahci-platform

In reply to Frank Wunderlich

From: Frank Wunderlich <[email protected]>

Some SoC using power-domains property so add it here

Signed-off-by Frank Wunderlich <[email protected]>

---
changes in v3:
- new patch

---
 Documentation/devicetree/bindings/ata/ahci-platform.yaml | 3 +++
 1 file changed, 3 insertions(+)
Documentation/devicetree/bindings/ata/ahci-platform.yaml +3 -0
index cc246b312c59..cc3710fe4fd4 100644
@@ -67,6 +67,9 @@ properties:
       some embedded SoCs.
     minItems: 1
 
+  power-domains:
+    maxItems: 1
+
   resets:
     minItems: 1
Signature · 1 line
2.25.1
#10 lore raw

Re: [PATCH v3 2/3] dt-bindings: Add power-domains property to ahci-platform

Quoted 3 lines · Frank Wunderlich

From: Frank Wunderlich <[email protected]>

Some SoC using power-domains property so add it here

Full stop.

Subject: "dt-bindings: ata: ahci-platform: Add power-domains property"

Quoted 14 lines
Signed-off-by Frank Wunderlich <[email protected]>

---
changes in v3:
- new patch

---
 Documentation/devicetree/bindings/ata/ahci-platform.yaml | 3 +++
 1 file changed, 3 insertions(+)
Documentation/devicetree/bindings/ata/ahci-platform.yaml +0 -0
index cc246b312c59..cc3710fe4fd4 100644

Documentation/devicetree/bindings/ata/ahci-platform.yaml properties: · line 75

Quoted 9 lines
Documentation/devicetree/bindings/ata/ahci-platform.yaml +3 -0
@@ -67,6 +67,9 @@ properties:
       some embedded SoCs.
     minItems: 1
 
+  power-domains:
+    maxItems: 1
+
   resets:
     minItems: 1

Best regards,
Krzysztof

author
#11 lore raw

PATCH v3 3/3 arm64: dts: rockchip: Add sata nodes to rk356x

In reply to Frank Wunderlich

From: Frank Wunderlich <[email protected]>

RK356x supports up to 3 sata controllers which were compatible with the existing snps,dwc-ahci binding.

Signed-off-by Frank Wunderlich <[email protected]>

---
changes in v3:
- fix combphy error by moving sata0 to rk3568.dtsi
- remove clock-names and interrupt-names
changes in v2:
- added sata0 + 1, but have only tested sata2

---
 arch/arm64/boot/dts/rockchip/rk3568.dtsi | 14 +++++++++++++
 arch/arm64/boot/dts/rockchip/rk356x.dtsi | 26 ++++++++++++++++++++++++
 2 files changed, 40 insertions(+)
arch/arm64/boot/dts/rockchip/rk3568.dtsi +14 -0
index 5b0f528d6818..2a2f65899d47 100644
@@ -8,6 +8,19 @@
 / {
 	compatible = "rockchip,rk3568";
 
+	sata0: sata@fc000000 {
+		compatible = "snps,dwc-ahci";
+		reg = <0 0xfc000000 0 0x1000>;
+		clocks = <&cru ACLK_SATA0>, <&cru CLK_SATA0_PMALIVE>,
+			 <&cru CLK_SATA0_RXOOB>;
+		interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+		phys = <&combphy0 PHY_TYPE_SATA>;
+		phy-names = "sata-phy";
+		ports-implemented = <0x1>;
+		power-domains = <&power RK3568_PD_PIPE>;
+		status = "disabled";
+	};
+
 	pipe_phy_grf0: syscon@fdc70000 {
 		compatible = "rockchip,rk3568-pipe-phy-grf", "syscon";
 		reg = <0x0 0xfdc70000 0x0 0x1000>;

@@ -114,3 +127,4 @@ power-domain@RK3568_PD_PIPE {
 		#power-domain-cells = <0>;
 	};
 };
+
arch/arm64/boot/dts/rockchip/rk356x.dtsi +26 -0
index 7cdef800cb3c..484c5ace718a 100644
@@ -230,6 +230,32 @@ scmi_shmem: sram@0 {
 		};
 	};
 
+	sata1: sata@fc400000 {
+		compatible = "snps,dwc-ahci";
+		reg = <0 0xfc400000 0 0x1000>;
+		clocks = <&cru ACLK_SATA1>, <&cru CLK_SATA1_PMALIVE>,
+			 <&cru CLK_SATA1_RXOOB>;
+		interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
+		phys = <&combphy1 PHY_TYPE_SATA>;
+		phy-names = "sata-phy";
+		ports-implemented = <0x1>;
+		power-domains = <&power RK3568_PD_PIPE>;
+		status = "disabled";
+	};
+
+	sata2: sata@fc800000 {
+		compatible = "snps,dwc-ahci";
+		reg = <0 0xfc800000 0 0x1000>;
+		clocks = <&cru ACLK_SATA2>, <&cru CLK_SATA2_PMALIVE>,
+			 <&cru CLK_SATA2_RXOOB>;
+		interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
+		phys = <&combphy2 PHY_TYPE_SATA>;
+		phy-names = "sata-phy";
+		ports-implemented = <0x1>;
+		power-domains = <&power RK3568_PD_PIPE>;
+		status = "disabled";
+	};
+
 	gic: interrupt-controller@fd400000 {
 		compatible = "arm,gic-v3";
 		reg = <0x0 0xfd400000 0 0x10000>, /* GICD */
Signature · 1 line
2.25.1
#12 lore raw

Re: [PATCH v3 3/3] arm64: dts: rockchip: Add sata nodes to rk356x

Hi Frank,

Quoted 22 lines · Frank Wunderlich

From: Frank Wunderlich <[email protected]>

RK356x supports up to 3 sata controllers which were compatible with the existing snps,dwc-ahci binding.

Signed-off-by Frank Wunderlich <[email protected]>

---
changes in v3:
- fix combphy error by moving sata0 to rk3568.dtsi
- remove clock-names and interrupt-names
changes in v2:
- added sata0 + 1, but have only tested sata2

---
 arch/arm64/boot/dts/rockchip/rk3568.dtsi | 14 +++++++++++++
 arch/arm64/boot/dts/rockchip/rk356x.dtsi | 26 ++++++++++++++++++++++++
 2 files changed, 40 insertions(+)
arch/arm64/boot/dts/rockchip/rk3568.dtsi +0 -0
index 5b0f528d6818..2a2f65899d47 100644

arch/arm64/boot/dts/rockchip/rk3568.dtsi line 13

Quoted 6 lines
arch/arm64/boot/dts/rockchip/rk3568.dtsi +2 -0
@@ -8,6 +8,19 @@
 / {
 	compatible = "rockchip,rk3568";
 
+	sata0: sata@fc000000 {
 
+		compatible = "snps,dwc-ahci";

		compatible = "rockchip,rk3568-dwc-ahci", "snps,dwc-ahci";

Compatible strings must be SoC orientated.
By using a fall back string the driver doesn't have to be changed for every new SoC.
Add binding in extra patch.

Quoted 24 lines
arch/arm64/boot/dts/rockchip/rk3568.dtsi +11 -0
+		reg = <0 0xfc000000 0 0x1000>;
+		clocks = <&cru ACLK_SATA0>, <&cru CLK_SATA0_PMALIVE>,
+			 <&cru CLK_SATA0_RXOOB>;
+		interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+		phys = <&combphy0 PHY_TYPE_SATA>;
+		phy-names = "sata-phy";
+		ports-implemented = <0x1>;
+		power-domains = <&power RK3568_PD_PIPE>;
+		status = "disabled";
+	};
+
 	pipe_phy_grf0: syscon@fdc70000 {
 		compatible = "rockchip,rk3568-pipe-phy-grf", "syscon";
arch/arm64/boot/dts/rockchip/rk3568.dtsi +1 -0
 		reg = <0x0 0xfdc70000 0x0 0x1000>;

@@ -114,3 +127,4 @@ power-domain@RK3568_PD_PIPE {
 		#power-domain-cells = <0>;
 	};
 };
+
arch/arm64/boot/dts/rockchip/rk356x.dtsi +0 -0
index 7cdef800cb3c..484c5ace718a 100644

arch/arm64/boot/dts/rockchip/rk356x.dtsi scmi_shmem: sram@0 { · line 235

Quoted 6 lines
arch/arm64/boot/dts/rockchip/rk356x.dtsi +2 -0
@@ -230,6 +230,32 @@ scmi_shmem: sram@0 {
 		};
 	};
 
+	sata1: sata@fc400000 {
 
+		compatible = "snps,dwc-ahci";

dito

Quoted 4 lines
arch/arm64/boot/dts/rockchip/rk356x.dtsi +4 -0
+		reg = <0 0xfc400000 0 0x1000>;
+		clocks = <&cru ACLK_SATA1>, <&cru CLK_SATA1_PMALIVE>,
+			 <&cru CLK_SATA1_RXOOB>;
+		interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;

arch/arm64/boot/dts/rockchip/rk356x.dtsi scmi_shmem: sram@0 { · line 247

Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk356x.dtsi +9 -0
+		phys = <&combphy1 PHY_TYPE_SATA>;
+		phy-names = "sata-phy";
+		ports-implemented = <0x1>;
+		power-domains = <&power RK3568_PD_PIPE>;
+		status = "disabled";
+	};
+
+	sata2: sata@fc800000 {
 
+		compatible = "snps,dwc-ahci";

dito

Quoted 14 lines
arch/arm64/boot/dts/rockchip/rk356x.dtsi +11 -0
+		reg = <0 0xfc800000 0 0x1000>;
+		clocks = <&cru ACLK_SATA2>, <&cru CLK_SATA2_PMALIVE>,
+			 <&cru CLK_SATA2_RXOOB>;
+		interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
+		phys = <&combphy2 PHY_TYPE_SATA>;
+		phy-names = "sata-phy";
+		ports-implemented = <0x1>;
+		power-domains = <&power RK3568_PD_PIPE>;
+		status = "disabled";
+	};
+
 	gic: interrupt-controller@fd400000 {
arch/arm64/boot/dts/rockchip/rk356x.dtsi +0 -0
 		compatible = "arm,gic-v3";
 		reg = <0x0 0xfd400000 0 0x10000>, /* GICD */
#13 lore raw

Re: [PATCH v3 3/3] arm64: dts: rockchip: Add sata nodes to rk356x

In reply to Frank Wunderlich
Quoted 42 lines · Frank Wunderlich

From: Frank Wunderlich <[email protected]>

RK356x supports up to 3 sata controllers which were compatible with the existing snps,dwc-ahci binding.

Signed-off-by Frank Wunderlich <[email protected]>

---
changes in v3:
- fix combphy error by moving sata0 to rk3568.dtsi
- remove clock-names and interrupt-names
changes in v2:
- added sata0 + 1, but have only tested sata2

---
 arch/arm64/boot/dts/rockchip/rk3568.dtsi | 14 +++++++++++++
 arch/arm64/boot/dts/rockchip/rk356x.dtsi | 26 ++++++++++++++++++++++++
 2 files changed, 40 insertions(+)
arch/arm64/boot/dts/rockchip/rk3568.dtsi +13 -0
index 5b0f528d6818..2a2f65899d47 100644
@@ -8,6 +8,19 @@
 / {
 	compatible = "rockchip,rk3568";
 
+	sata0: sata@fc000000 {
+		compatible = "snps,dwc-ahci";
+		reg = <0 0xfc000000 0 0x1000>;
+		clocks = <&cru ACLK_SATA0>, <&cru CLK_SATA0_PMALIVE>,
+			 <&cru CLK_SATA0_RXOOB>;
+		interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+		phys = <&combphy0 PHY_TYPE_SATA>;
+		phy-names = "sata-phy";
+		ports-implemented = <0x1>;
+		power-domains = <&power RK3568_PD_PIPE>;
+		status = "disabled";
+	};
+
 	pipe_phy_grf0: syscon@fdc70000 {
 		compatible = "rockchip,rk3568-pipe-phy-grf", "syscon";
 		reg = <0x0 0xfdc70000 0x0 0x1000>;

arch/arm64/boot/dts/rockchip/rk3568.dtsi power-domain@RK3568_PD_PIPE { · line 130

Quoted 4 lines
arch/arm64/boot/dts/rockchip/rk3568.dtsi +1 -0
@@ -114,3 +127,4 @@ power-domain@RK3568_PD_PIPE {
 		#power-domain-cells = <0>;
 	};
 };
+

No need for new line here,

arch/arm64/boot/dts/rockchip/rk356x.dtsi scmi_shmem: sram@0 { · line 237

Quoted 13 lines
arch/arm64/boot/dts/rockchip/rk356x.dtsi +5 -0
index 7cdef800cb3c..484c5ace718a 100644
@@ -230,6 +230,32 @@ scmi_shmem: sram@0 {
 		};
 	};
 
+	sata1: sata@fc400000 {
+		compatible = "snps,dwc-ahci";
+		reg = <0 0xfc400000 0 0x1000>;
+		clocks = <&cru ACLK_SATA1>, <&cru CLK_SATA1_PMALIVE>,
+			 <&cru CLK_SATA1_RXOOB>;

clock-names should be added. Also to bindings.

Best regards,
Krzysztof