2024-04-01 15:38:09

by Krzysztof Kozlowski

[permalink] [raw]
Subject: [PATCH RFT 01/10] arm64: dts: microchip: sparx5: fix mdio reg

Correct the reg address of mdio node to match unit address. Assume the
reg is not correct and unit address was correct, because there is
alerady node using the existing reg 0x110102d4.

sparx5.dtsi:443.25-451.5: Warning (simple_bus_reg): /axi@600000000/mdio@6110102f8: simple-bus unit address format error, expected "6110102d4"

Fixes: d0f482bb06f9 ("arm64: dts: sparx5: Add the Sparx5 switch node")
Signed-off-by: Krzysztof Kozlowski <[email protected]>

---

Not tested on hardware
---
arch/arm64/boot/dts/microchip/sparx5.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi b/arch/arm64/boot/dts/microchip/sparx5.dtsi
index 24075cd91420..5d820da8c69d 100644
--- a/arch/arm64/boot/dts/microchip/sparx5.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
@@ -447,7 +447,7 @@ mdio2: mdio@6110102f8 {
pinctrl-names = "default";
#address-cells = <1>;
#size-cells = <0>;
- reg = <0x6 0x110102d4 0x24>;
+ reg = <0x6 0x110102f8 0x24>;
};

mdio3: mdio@61101031c {
--
2.34.1



2024-04-01 15:38:17

by Krzysztof Kozlowski

[permalink] [raw]
Subject: [PATCH 02/10] arm64: dts: microchip: sparx5: correct serdes unit address

Unit address should match "reg" property, as reported by dtc W=1
warnings:

sparx5.dtsi:463.27-468.5: Warning (simple_bus_reg): /axi@600000000/serdes@10808000: simple-bus unit address format error, expected "610808000"

Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
arch/arm64/boot/dts/microchip/sparx5.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi b/arch/arm64/boot/dts/microchip/sparx5.dtsi
index 5d820da8c69d..c3029e0abacc 100644
--- a/arch/arm64/boot/dts/microchip/sparx5.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
@@ -460,7 +460,7 @@ mdio3: mdio@61101031c {
reg = <0x6 0x1101031c 0x24>;
};

- serdes: serdes@10808000 {
+ serdes: serdes@610808000 {
compatible = "microchip,sparx5-serdes";
#phy-cells = <1>;
clocks = <&sys_clk>;
--
2.34.1


2024-04-01 15:38:30

by Krzysztof Kozlowski

[permalink] [raw]
Subject: [PATCH 03/10] arm64: dts: microchip: sparx5_pcb134: add missing I2C mux unit addresses

The children of I2C mux should be named "i2c", according to DT schema
and bindings, and they should have unit address.

This fixes dtbs_check warnings like:

sparx5_pcb134_emmc.dtb: i2c0-imux@0: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'i2c_sfp1', ...

and dtc W=1 warnings:

sparx5_pcb134_board.dtsi:548.23-555.4: Warning (simple_bus_reg): /axi@600000000/sfp-eth12: missing or empty reg/ranges property

Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
.../dts/microchip/sparx5_pcb134_board.dtsi | 40 +++++++++----------
1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
index f3e226de5e5e..e816e6e9d62d 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
@@ -427,62 +427,62 @@ &i2c0_imux {
pinctrl-10 = <&i2cmux_10>;
pinctrl-11 = <&i2cmux_11>;
pinctrl-12 = <&i2cmux_pins_i>;
- i2c_sfp1: i2c_sfp1 {
+ i2c_sfp1: i2c@0 {
reg = <0x0>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp2: i2c_sfp2 {
+ i2c_sfp2: i2c@1 {
reg = <0x1>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp3: i2c_sfp3 {
+ i2c_sfp3: i2c@2 {
reg = <0x2>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp4: i2c_sfp4 {
+ i2c_sfp4: i2c@3 {
reg = <0x3>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp5: i2c_sfp5 {
+ i2c_sfp5: i2c@4 {
reg = <0x4>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp6: i2c_sfp6 {
+ i2c_sfp6: i2c@5 {
reg = <0x5>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp7: i2c_sfp7 {
+ i2c_sfp7: i2c@6 {
reg = <0x6>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp8: i2c_sfp8 {
+ i2c_sfp8: i2c@7 {
reg = <0x7>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp9: i2c_sfp9 {
+ i2c_sfp9: i2c@8 {
reg = <0x8>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp10: i2c_sfp10 {
+ i2c_sfp10: i2c@9 {
reg = <0x9>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp11: i2c_sfp11 {
+ i2c_sfp11: i2c@a {
reg = <0xa>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp12: i2c_sfp12 {
+ i2c_sfp12: i2c@b {
reg = <0xb>;
#address-cells = <1>;
#size-cells = <0>;
@@ -495,42 +495,42 @@ &gpio 60 GPIO_ACTIVE_HIGH
&gpio 61 GPIO_ACTIVE_HIGH
&gpio 54 GPIO_ACTIVE_HIGH>;
idle-state = <0x8>;
- i2c_sfp13: i2c_sfp13 {
+ i2c_sfp13: i2c@0 {
reg = <0x0>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp14: i2c_sfp14 {
+ i2c_sfp14: i2c@1 {
reg = <0x1>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp15: i2c_sfp15 {
+ i2c_sfp15: i2c@2 {
reg = <0x2>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp16: i2c_sfp16 {
+ i2c_sfp16: i2c@3 {
reg = <0x3>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp17: i2c_sfp17 {
+ i2c_sfp17: i2c@4 {
reg = <0x4>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp18: i2c_sfp18 {
+ i2c_sfp18: i2c@5 {
reg = <0x5>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp19: i2c_sfp19 {
+ i2c_sfp19: i2c@6 {
reg = <0x6>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp20: i2c_sfp20 {
+ i2c_sfp20: i2c@7 {
reg = <0x7>;
#address-cells = <1>;
#size-cells = <0>;
--
2.34.1


2024-04-01 15:38:44

by Krzysztof Kozlowski

[permalink] [raw]
Subject: [PATCH 04/10] arm64: dts: microchip: sparx5_pcb135: add missing I2C mux unit addresses

The children of I2C mux should be named "i2c", according to DT schema
and bindings, and they should have unit address.

This fixes dtbs_check warnings like:

sparx5_pcb135.dtb: i2c0-imux@0: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'i2c_sfp1', 'i2c_sfp2', 'i2c_sfp3', 'i2c_sfp4' were unexpected)

and dtc W=1 warnings:

sparx5_pcb135_board.dtsi:172.23-180.4: Warning (simple_bus_reg): /axi@600000000/sfp-eth60: missing or empty reg/ranges property

Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
index 82ce007d9959..bf51a6e11cf1 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
@@ -146,22 +146,22 @@ &i2c0_imux {
pinctrl-2 = <&i2cmux_s31>;
pinctrl-3 = <&i2cmux_s32>;
pinctrl-4 = <&i2cmux_pins_i>;
- i2c_sfp1: i2c_sfp1 {
+ i2c_sfp1: i2c@0 {
reg = <0x0>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp2: i2c_sfp2 {
+ i2c_sfp2: i2c@1 {
reg = <0x1>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp3: i2c_sfp3 {
+ i2c_sfp3: i2c@2 {
reg = <0x2>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp4: i2c_sfp4 {
+ i2c_sfp4: i2c@3 {
reg = <0x3>;
#address-cells = <1>;
#size-cells = <0>;
--
2.34.1


2024-04-01 15:38:57

by Krzysztof Kozlowski

[permalink] [raw]
Subject: [PATCH 05/10] arm64: dts: microchip: sparx5_pcb134: align I2C mux node name with bindings

DT schema expects node names to match certain. This fixes dtbs_check
warnings like:

sparx5_pcb134_emmc.dtb: i2c0-emux@0: $nodename:0: 'i2c0-emux@0' does not match '^(i2c-?)?mux'

and dtc W=1 warnings:

sparx5_pcb134_board.dtsi:398.25-403.4: Warning (unique_unit_address_if_enabled): /axi@600000000/i2c0-imux@0: duplicate unit-address (also used in node /axi@600000000/i2c0-emux@0)

Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
index e816e6e9d62d..cafec6ef0d0f 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
@@ -395,13 +395,13 @@ i2cmux_11: i2cmux-11-pins {
};

&axi {
- i2c0_imux: i2c0-imux@0 {
+ i2c0_imux: i2c-mux-0 {
compatible = "i2c-mux-pinctrl";
#address-cells = <1>;
#size-cells = <0>;
i2c-parent = <&i2c0>;
};
- i2c0_emux: i2c0-emux@0 {
+ i2c0_emux: i2c-mux-1 {
compatible = "i2c-mux-gpio";
#address-cells = <1>;
#size-cells = <0>;
--
2.34.1


2024-04-01 15:39:31

by Krzysztof Kozlowski

[permalink] [raw]
Subject: [PATCH 06/10] arm64: dts: microchip: sparx5_pcb135: align I2C mux node name with bindings

DT schema expects node names to match certain. This fixes dtbs_check
warnings like:

sparx5_pcb135_emmc.dtb: i2c0-imux@0: $nodename:0: 'i2c0-imux@0' does not match '^(i2c-?)?mux'

and dtc W=1 warnings:

sparx5_pcb135_board.dtsi:132.25-137.4: Warning (simple_bus_reg): /axi@600000000/i2c0-imux@0: missing or empty reg/ranges property

Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
index bf51a6e11cf1..860975ffe0a1 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
@@ -129,7 +129,7 @@ &sgpio2 {
};

&axi {
- i2c0_imux: i2c0-imux@0 {
+ i2c0_imux: i2c-mux {
compatible = "i2c-mux-pinctrl";
#address-cells = <1>;
#size-cells = <0>;
--
2.34.1


2024-04-01 15:39:37

by Krzysztof Kozlowski

[permalink] [raw]
Subject: [PATCH 08/10] arm64: dts: microchip: sparx5_pcb135: drop LED unit addresses

GPIO leds should not have unit addresses (no "reg" property), as
reported by dtc W=1 warnings:

sparx5_pcb135_board.dtsi:18.9-22.5: Warning (unit_address_vs_reg): /leds/led@0: node has a unit name, but no reg or ranges property

Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
.../boot/dts/microchip/sparx5_pcb135_board.dtsi | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
index 860975ffe0a1..20016efb3656 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
@@ -15,42 +15,42 @@ gpio-restart {

leds {
compatible = "gpio-leds";
- led@0 {
+ led-0 {
label = "eth60:yellow";
gpios = <&sgpio_out1 28 0 GPIO_ACTIVE_LOW>;
default-state = "off";
};
- led@1 {
+ led-1 {
label = "eth60:green";
gpios = <&sgpio_out1 28 1 GPIO_ACTIVE_LOW>;
default-state = "off";
};
- led@2 {
+ led-2 {
label = "eth61:yellow";
gpios = <&sgpio_out1 29 0 GPIO_ACTIVE_LOW>;
default-state = "off";
};
- led@3 {
+ led-3 {
label = "eth61:green";
gpios = <&sgpio_out1 29 1 GPIO_ACTIVE_LOW>;
default-state = "off";
};
- led@4 {
+ led-4 {
label = "eth62:yellow";
gpios = <&sgpio_out1 30 0 GPIO_ACTIVE_LOW>;
default-state = "off";
};
- led@5 {
+ led-5 {
label = "eth62:green";
gpios = <&sgpio_out1 30 1 GPIO_ACTIVE_LOW>;
default-state = "off";
};
- led@6 {
+ led-6 {
label = "eth63:yellow";
gpios = <&sgpio_out1 31 0 GPIO_ACTIVE_LOW>;
default-state = "off";
};
- led@7 {
+ led-7 {
label = "eth63:green";
gpios = <&sgpio_out1 31 1 GPIO_ACTIVE_LOW>;
default-state = "off";
--
2.34.1


2024-04-01 15:39:48

by Krzysztof Kozlowski

[permalink] [raw]
Subject: [PATCH 07/10] arm64: dts: microchip: sparx5_pcb134: drop LED unit addresses

GPIO leds should not have unit addresses (no "reg" property), as
reported by dtc W=1 warnings:

sparx5_pcb134_board.dtsi:18.9-21.5: Warning (unit_address_vs_reg): /leds/led@0: node has a unit name, but no reg or ranges property

Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
.../dts/microchip/sparx5_pcb134_board.dtsi | 96 +++++++++----------
1 file changed, 48 insertions(+), 48 deletions(-)

diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
index cafec6ef0d0f..f165a409bc1d 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
@@ -15,234 +15,234 @@ gpio-restart {

leds {
compatible = "gpio-leds";
- led@0 {
+ led-0 {
label = "twr0:green";
gpios = <&sgpio_out0 8 0 GPIO_ACTIVE_LOW>;
};
- led@1 {
+ led-1 {
label = "twr0:yellow";
gpios = <&sgpio_out0 8 1 GPIO_ACTIVE_LOW>;
};
- led@2 {
+ led-2 {
label = "twr1:green";
gpios = <&sgpio_out0 9 0 GPIO_ACTIVE_LOW>;
};
- led@3 {
+ led-3 {
label = "twr1:yellow";
gpios = <&sgpio_out0 9 1 GPIO_ACTIVE_LOW>;
};
- led@4 {
+ led-4 {
label = "twr2:green";
gpios = <&sgpio_out0 10 0 GPIO_ACTIVE_LOW>;
};
- led@5 {
+ led-5 {
label = "twr2:yellow";
gpios = <&sgpio_out0 10 1 GPIO_ACTIVE_LOW>;
};
- led@6 {
+ led-6 {
label = "twr3:green";
gpios = <&sgpio_out0 11 0 GPIO_ACTIVE_LOW>;
};
- led@7 {
+ led-7 {
label = "twr3:yellow";
gpios = <&sgpio_out0 11 1 GPIO_ACTIVE_LOW>;
};
- led@8 {
+ led-8 {
label = "eth12:green";
gpios = <&sgpio_out0 12 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@9 {
+ led-9 {
label = "eth12:yellow";
gpios = <&sgpio_out0 12 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@10 {
+ led-10 {
label = "eth13:green";
gpios = <&sgpio_out0 13 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@11 {
+ led-11 {
label = "eth13:yellow";
gpios = <&sgpio_out0 13 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@12 {
+ led-12 {
label = "eth14:green";
gpios = <&sgpio_out0 14 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@13 {
+ led-13 {
label = "eth14:yellow";
gpios = <&sgpio_out0 14 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@14 {
+ led-14 {
label = "eth15:green";
gpios = <&sgpio_out0 15 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@15 {
+ led-15 {
label = "eth15:yellow";
gpios = <&sgpio_out0 15 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@16 {
+ led-16 {
label = "eth48:green";
gpios = <&sgpio_out1 16 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@17 {
+ led-17 {
label = "eth48:yellow";
gpios = <&sgpio_out1 16 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@18 {
+ led-18 {
label = "eth49:green";
gpios = <&sgpio_out1 17 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@19 {
+ led-19 {
label = "eth49:yellow";
gpios = <&sgpio_out1 17 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@20 {
+ led-20 {
label = "eth50:green";
gpios = <&sgpio_out1 18 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@21 {
+ led-21 {
label = "eth50:yellow";
gpios = <&sgpio_out1 18 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@22 {
+ led-22 {
label = "eth51:green";
gpios = <&sgpio_out1 19 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@23 {
+ led-23 {
label = "eth51:yellow";
gpios = <&sgpio_out1 19 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@24 {
+ led-24 {
label = "eth52:green";
gpios = <&sgpio_out1 20 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@25 {
+ led-25 {
label = "eth52:yellow";
gpios = <&sgpio_out1 20 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@26 {
+ led-26 {
label = "eth53:green";
gpios = <&sgpio_out1 21 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@27 {
+ led-27 {
label = "eth53:yellow";
gpios = <&sgpio_out1 21 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@28 {
+ led-28 {
label = "eth54:green";
gpios = <&sgpio_out1 22 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@29 {
+ led-29 {
label = "eth54:yellow";
gpios = <&sgpio_out1 22 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@30 {
+ led-30 {
label = "eth55:green";
gpios = <&sgpio_out1 23 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@31 {
+ led-31 {
label = "eth55:yellow";
gpios = <&sgpio_out1 23 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@32 {
+ led-32 {
label = "eth56:green";
gpios = <&sgpio_out1 24 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@33 {
+ led-33 {
label = "eth56:yellow";
gpios = <&sgpio_out1 24 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@34 {
+ led-34 {
label = "eth57:green";
gpios = <&sgpio_out1 25 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@35 {
+ led-35 {
label = "eth57:yellow";
gpios = <&sgpio_out1 25 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@36 {
+ led-36 {
label = "eth58:green";
gpios = <&sgpio_out1 26 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@37 {
+ led-37 {
label = "eth58:yellow";
gpios = <&sgpio_out1 26 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@38 {
+ led-38 {
label = "eth59:green";
gpios = <&sgpio_out1 27 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@39 {
+ led-39 {
label = "eth59:yellow";
gpios = <&sgpio_out1 27 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@40 {
+ led-40 {
label = "eth60:green";
gpios = <&sgpio_out1 28 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@41 {
+ led-41 {
label = "eth60:yellow";
gpios = <&sgpio_out1 28 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@42 {
+ led-42 {
label = "eth61:green";
gpios = <&sgpio_out1 29 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@43 {
+ led-43 {
label = "eth61:yellow";
gpios = <&sgpio_out1 29 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@44 {
+ led-44 {
label = "eth62:green";
gpios = <&sgpio_out1 30 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@45 {
+ led-45 {
label = "eth62:yellow";
gpios = <&sgpio_out1 30 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@46 {
+ led-46 {
label = "eth63:green";
gpios = <&sgpio_out1 31 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@47 {
+ led-47 {
label = "eth63:yellow";
gpios = <&sgpio_out1 31 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
--
2.34.1


2024-04-01 15:39:50

by Krzysztof Kozlowski

[permalink] [raw]
Subject: [PATCH RFT 09/10] arm64: dts: microchip: sparx5_pcb134: drop duplicated NOR flash

Since beginning the DTS extended the SPI0 in two places adding two SPI
muxes, each with same SPI NOR flash. Both used exactly the same
chip-selects, so this was clearly buggy code. Without checking in
datasheet, assume device has only one SPI NOR flash, so code was
duplicated.

Fixes dtc W=1 warnings:

sparx5_pcb134_board.dtsi:277.10-281.4: Warning (unique_unit_address_if_enabled): /axi@600000000/spi@600104000/flash@0: duplicate unit-address (also used in node /axi@600000000/spi@600104000/spi@0)

Signed-off-by: Krzysztof Kozlowski <[email protected]>

---

Not tested on hardware
---
.../boot/dts/microchip/sparx5_pcb134_board.dtsi | 16 ----------------
1 file changed, 16 deletions(-)

diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
index f165a409bc1d..dc7b59dfcb40 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
@@ -281,22 +281,6 @@ flash@0 {
};
};

-&spi0 {
- status = "okay";
- spi@0 {
- compatible = "spi-mux";
- mux-controls = <&mux>;
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0>; /* CS0 */
- flash@9 {
- compatible = "jedec,spi-nor";
- spi-max-frequency = <8000000>;
- reg = <0x9>; /* SPI */
- };
- };
-};
-
&sgpio0 {
status = "okay";
microchip,sgpio-port-ranges = <8 15>;
--
2.34.1


2024-04-01 15:40:43

by Krzysztof Kozlowski

[permalink] [raw]
Subject: [PATCH RFT 10/10] arm64: dts: microchip: sparx5_pcb135: drop duplicated NOR flash

Since beginning the DTS extended the SPI0 in two places adding two SPI
muxes, each with same SPI NOR flash. Both used exactly the same
chip-selects, so this was clearly buggy code. Without checking in
datasheet, assume device has only one SPI NOR flash, so code was
duplicated.

Fixes dtc W=1 warnings:

sparx5_pcb135_board.dtsi:92.10-96.4: Warning (unique_unit_address_if_enabled): /axi@600000000/spi@600104000/flash@0: duplicate unit-address (also used in node /axi@600000000/spi@600104000/spi@0)

Signed-off-by: Krzysztof Kozlowski <[email protected]>

---

Not tested on hardware
---
.../boot/dts/microchip/sparx5_pcb135_board.dtsi | 16 ----------------
1 file changed, 16 deletions(-)

diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
index 20016efb3656..d64e642e3873 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
@@ -96,22 +96,6 @@ flash@0 {
};
};

-&spi0 {
- status = "okay";
- spi@0 {
- compatible = "spi-mux";
- mux-controls = <&mux>;
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0>; /* CS0 */
- flash@9 {
- compatible = "jedec,spi-nor";
- spi-max-frequency = <8000000>;
- reg = <0x9>; /* SPI */
- };
- };
-};
-
&sgpio1 {
status = "okay";
microchip,sgpio-port-ranges = <24 31>;
--
2.34.1


2024-04-02 06:27:03

by Horatiu Vultur

[permalink] [raw]
Subject: Re: [PATCH RFT 01/10] arm64: dts: microchip: sparx5: fix mdio reg

The 04/01/2024 17:37, Krzysztof Kozlowski wrote:

Hi,

I have not tested this patch on HW but I have checked the registers info
and this change seems correct.

Reviewed-by: Horatiu Vultur <[email protected]>


> Correct the reg address of mdio node to match unit address. Assume the
> reg is not correct and unit address was correct, because there is
> alerady node using the existing reg 0x110102d4.
>
> sparx5.dtsi:443.25-451.5: Warning (simple_bus_reg): /axi@600000000/mdio@6110102f8: simple-bus unit address format error, expected "6110102d4"
>
> Fixes: d0f482bb06f9 ("arm64: dts: sparx5: Add the Sparx5 switch node")
> Signed-off-by: Krzysztof Kozlowski <[email protected]>
>
> ---
>
> Not tested on hardware
> ---
> arch/arm64/boot/dts/microchip/sparx5.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi b/arch/arm64/boot/dts/microchip/sparx5.dtsi
> index 24075cd91420..5d820da8c69d 100644
> --- a/arch/arm64/boot/dts/microchip/sparx5.dtsi
> +++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
> @@ -447,7 +447,7 @@ mdio2: mdio@6110102f8 {
> pinctrl-names = "default";
> #address-cells = <1>;
> #size-cells = <0>;
> - reg = <0x6 0x110102d4 0x24>;
> + reg = <0x6 0x110102f8 0x24>;
> };
>
> mdio3: mdio@61101031c {
> --
> 2.34.1
>

--
/Horatiu

2024-04-02 14:01:06

by Steen Hegelund

[permalink] [raw]
Subject: Re: [PATCH RFT 01/10] arm64: dts: microchip: sparx5: fix mdio reg

Hi Krzysztof,


On Mon, 2024-04-01 at 17:37 +0200, Krzysztof Kozlowski wrote:
> [Some people who received this message don't often get email from
> [email protected]. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
>
> Correct the reg address of mdio node to match unit address.  Assume
> the
> reg is not correct and unit address was correct, because there is
> alerady node using the existing reg 0x110102d4.
>
>   sparx5.dtsi:443.25-451.5: Warning (simple_bus_reg):
> /axi@600000000/mdio@6110102f8: simple-bus unit address format error,
> expected "6110102d4"
>
> Fixes: d0f482bb06f9 ("arm64: dts: sparx5: Add the Sparx5 switch
> node")
> Signed-off-by: Krzysztof Kozlowski <[email protected]>
>
> ---
>
> Not tested on hardware
> ---
>  arch/arm64/boot/dts/microchip/sparx5.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi
> b/arch/arm64/boot/dts/microchip/sparx5.dtsi
> index 24075cd91420..5d820da8c69d 100644
> --- a/arch/arm64/boot/dts/microchip/sparx5.dtsi
> +++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
> @@ -447,7 +447,7 @@ mdio2: mdio@6110102f8 {
>                         pinctrl-names = "default";
>                         #address-cells = <1>;
>                         #size-cells = <0>;
> -                       reg = <0x6 0x110102d4 0x24>;
> +                       reg = <0x6 0x110102f8 0x24>;
>                 };
>
>                 mdio3: mdio@61101031c {
> --
> 2.34.1
>

I did a check of our current Sparx5 EVBs and none of them uses
controller 2 in any revision, so this is probably why it has not come
up before, so as it stands we have no platform to test this change on
currently.

Besides that the change looks good to me.

Best Regards
Steen

Reviewed-by: Steen Hegelund <[email protected]>



2024-04-02 17:47:08

by Conor Dooley

[permalink] [raw]
Subject: Re: [PATCH RFT 01/10] arm64: dts: microchip: sparx5: fix mdio reg

Hey,

On Tue, Apr 02, 2024 at 04:00:32PM +0200, Steen Hegelund wrote:
> On Mon, 2024-04-01 at 17:37 +0200, Krzysztof Kozlowski wrote:
> > [Some people who received this message don't often get email from
> > [email protected]. Learn why this is important at
> > https://aka.ms/LearnAboutSenderIdentification?]
> >
> > EXTERNAL EMAIL: Do not click links or open attachments unless you
> > know the content is safe
> >
> > Correct the reg address of mdio node to match unit address.? Assume
> > the
> > reg is not correct and unit address was correct, because there is
> > alerady node using the existing reg 0x110102d4.
> >
> > ? sparx5.dtsi:443.25-451.5: Warning (simple_bus_reg):
> > /axi@600000000/mdio@6110102f8: simple-bus unit address format error,
> > expected "6110102d4"
> >
> > Fixes: d0f482bb06f9 ("arm64: dts: sparx5: Add the Sparx5 switch
> > node")
> > Signed-off-by: Krzysztof Kozlowski <[email protected]>
> >
> > ---
> >
> > Not tested on hardware
> > ---
> > ?arch/arm64/boot/dts/microchip/sparx5.dtsi | 2 +-
> > ?1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi
> > b/arch/arm64/boot/dts/microchip/sparx5.dtsi
> > index 24075cd91420..5d820da8c69d 100644
> > --- a/arch/arm64/boot/dts/microchip/sparx5.dtsi
> > +++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
> > @@ -447,7 +447,7 @@ mdio2: mdio@6110102f8 {
> > ??????????????????????? pinctrl-names = "default";
> > ??????????????????????? #address-cells = <1>;
> > ??????????????????????? #size-cells = <0>;
> > -?????????????????????? reg = <0x6 0x110102d4 0x24>;
> > +?????????????????????? reg = <0x6 0x110102f8 0x24>;
> > ??????????????? };
> >
> > ??????????????? mdio3: mdio@61101031c {
> > --
> > 2.34.1
> >
>
> I did a check of our current Sparx5 EVBs and none of them uses
> controller 2 in any revision, so this is probably why it has not come
> up before, so as it stands we have no platform to test this change on
> currently.
>
> Besides that the change looks good to me.
>
> Best Regards
> Steen
>
> Reviewed-by: Steen Hegelund <[email protected]>

Are you okay with the rest of the series, or have you only looked at
this one patch?


Attachments:
(No filename) (2.21 kB)
signature.asc (235.00 B)
Download all attachments

2024-04-03 13:06:39

by Steen Hegelund

[permalink] [raw]
Subject: Re: [PATCH RFT 01/10] arm64: dts: microchip: sparx5: fix mdio reg

Hi Connor,

On Tue, 2024-04-02 at 18:46 +0100, Conor Dooley wrote:
> [Some people who received this message don't often get email from
> [email protected]. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe


I will also be looking at the other RFT marked patches, I just have not
had the time to do it yet...

BR
Steen


2024-04-05 12:11:14

by Steen Hegelund

[permalink] [raw]
Subject: Re: [PATCH RFT 09/10] arm64: dts: microchip: sparx5_pcb134: drop duplicated NOR flash

Hi Krzysztof,

On Mon, 2024-04-01 at 17:37 +0200, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> Since beginning the DTS extended the SPI0 in two places adding two SPI
> muxes, each with same SPI NOR flash.  Both used exactly the same
> chip-selects, so this was clearly buggy code.  Without checking in
> datasheet, assume device has only one SPI NOR flash, so code was
> duplicated.
>
> Fixes dtc W=1 warnings:
>
>   sparx5_pcb134_board.dtsi:277.10-281.4: Warning (unique_unit_address_if_enabled):
> /axi@600000000/spi@600104000/flash@0: duplicate unit-address (also used in node
> /axi@600000000/spi@600104000/spi@0)
>
> Signed-off-by: Krzysztof Kozlowski <[email protected]>
>
> ---
>
> Not tested on hardware
> ---
>  .../boot/dts/microchip/sparx5_pcb134_board.dtsi  | 16 ----------------
>  1 file changed, 16 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
> b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
> index f165a409bc1d..dc7b59dfcb40 100644
> --- a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
> +++ b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
> @@ -281,22 +281,6 @@ flash@0 {
>         };
>  };
>
> -&spi0 {
> -       status = "okay";
> -       spi@0 {
> -               compatible = "spi-mux";
> -               mux-controls = <&mux>;
> -               #address-cells = <1>;
> -               #size-cells = <0>;
> -               reg = <0>;      /* CS0 */
> -               flash@9 {
> -                       compatible = "jedec,spi-nor";
> -                       spi-max-frequency = <8000000>;
> -                       reg = <0x9>;    /* SPI */
> -               };
> -       };
> -};
> -

When testing this on actual HW the SPI NOR is no longer accessible.
The reason is that it sits behind a SPI-MUX and that needs to be present in the Device Tree.

So if you do the "reverse" clean-up it works fine: Remove the simple spi0 node and keep the one that
has the spi-mux reference.

>  &sgpio0 {
>         status = "okay";
>         microchip,sgpio-port-ranges = <8 15>;
> --
> 2.34.1
>

Thanks for the cleanup of the DT files!

Best Regards
Steen

2024-04-05 12:12:36

by Steen Hegelund

[permalink] [raw]
Subject: Re: [PATCH RFT 10/10] arm64: dts: microchip: sparx5_pcb135: drop duplicated NOR flash

Hi Krzysztof,

On Mon, 2024-04-01 at 17:37 +0200, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> Since beginning the DTS extended the SPI0 in two places adding two SPI
> muxes, each with same SPI NOR flash.  Both used exactly the same
> chip-selects, so this was clearly buggy code.  Without checking in
> datasheet, assume device has only one SPI NOR flash, so code was
> duplicated.
>
> Fixes dtc W=1 warnings:
>
>   sparx5_pcb135_board.dtsi:92.10-96.4: Warning (unique_unit_address_if_enabled):
> /axi@600000000/spi@600104000/flash@0: duplicate unit-address (also used in node
> /axi@600000000/spi@600104000/spi@0)
>
> Signed-off-by: Krzysztof Kozlowski <[email protected]>
>
> ---
>
> Not tested on hardware
> ---
>  .../boot/dts/microchip/sparx5_pcb135_board.dtsi  | 16 ----------------
>  1 file changed, 16 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
> b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
> index 20016efb3656..d64e642e3873 100644
> --- a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
> +++ b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
> @@ -96,22 +96,6 @@ flash@0 {
>         };
>  };
>
> -&spi0 {
> -       status = "okay";
> -       spi@0 {
> -               compatible = "spi-mux";
> -               mux-controls = <&mux>;
> -               #address-cells = <1>;
> -               #size-cells = <0>;
> -               reg = <0>; /* CS0 */
> -               flash@9 {
> -                       compatible = "jedec,spi-nor";
> -                       spi-max-frequency = <8000000>;
> -                       reg = <0x9>; /* SPI */
> -               };
> -       };
> -};
> -

I also tested this, and no surprise: same comment as for the pcb134 patch...

>  &sgpio1 {
>         status = "okay";
>         microchip,sgpio-port-ranges = <24 31>;
> --
> 2.34.1
>

Best Regards
Steen

2024-04-05 15:45:57

by Krzysztof Kozlowski

[permalink] [raw]
Subject: Re: [PATCH RFT 09/10] arm64: dts: microchip: sparx5_pcb134: drop duplicated NOR flash

On 05/04/2024 14:10, Steen Hegelund wrote:
> Hi Krzysztof,
>
> On Mon, 2024-04-01 at 17:37 +0200, Krzysztof Kozlowski wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> Since beginning the DTS extended the SPI0 in two places adding two SPI
>> muxes, each with same SPI NOR flash.  Both used exactly the same
>> chip-selects, so this was clearly buggy code.  Without checking in
>> datasheet, assume device has only one SPI NOR flash, so code was
>> duplicated.
>>
>> Fixes dtc W=1 warnings:
>>
>>   sparx5_pcb134_board.dtsi:277.10-281.4: Warning (unique_unit_address_if_enabled):
>> /axi@600000000/spi@600104000/flash@0: duplicate unit-address (also used in node
>> /axi@600000000/spi@600104000/spi@0)
>>
>> Signed-off-by: Krzysztof Kozlowski <[email protected]>
>>
>> ---
>>
>> Not tested on hardware
>> ---
>>  .../boot/dts/microchip/sparx5_pcb134_board.dtsi  | 16 ----------------
>>  1 file changed, 16 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
>> b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
>> index f165a409bc1d..dc7b59dfcb40 100644
>> --- a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
>> +++ b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
>> @@ -281,22 +281,6 @@ flash@0 {
>>         };
>>  };
>>
>> -&spi0 {
>> -       status = "okay";
>> -       spi@0 {
>> -               compatible = "spi-mux";
>> -               mux-controls = <&mux>;
>> -               #address-cells = <1>;
>> -               #size-cells = <0>;
>> -               reg = <0>;      /* CS0 */
>> -               flash@9 {
>> -                       compatible = "jedec,spi-nor";
>> -                       spi-max-frequency = <8000000>;
>> -                       reg = <0x9>;    /* SPI */
>> -               };
>> -       };
>> -};
>> -
>
> When testing this on actual HW the SPI NOR is no longer accessible.
> The reason is that it sits behind a SPI-MUX and that needs to be present in the Device Tree.
>
> So if you do the "reverse" clean-up it works fine: Remove the simple spi0 node and keep the one that
> has the spi-mux reference.

Aaaa, so we need to do it that way. Thanks for testing! I'll send v2.

Best regards,
Krzysztof


2024-04-05 15:59:14

by Krzysztof Kozlowski

[permalink] [raw]
Subject: Re: [PATCH RFT 10/10] arm64: dts: microchip: sparx5_pcb135: drop duplicated NOR flash

On 05/04/2024 14:11, Steen Hegelund wrote:
>>
>> -&spi0 {
>> -       status = "okay";
>> -       spi@0 {
>> -               compatible = "spi-mux";
>> -               mux-controls = <&mux>;
>> -               #address-cells = <1>;
>> -               #size-cells = <0>;
>> -               reg = <0>; /* CS0 */
>> -               flash@9 {
>> -                       compatible = "jedec,spi-nor";
>> -                       spi-max-frequency = <8000000>;
>> -                       reg = <0x9>; /* SPI */
>> -               };
>> -       };
>> -};
>> -
>
> I also tested this, and no surprise: same comment as for the pcb134 patch...

Thanks, I will send v2.

Best regards,
Krzysztof