* [PATCH 08/10] arm64: dts: microchip: sparx5_pcb135: drop LED unit addresses
From: Krzysztof Kozlowski @ 2024-04-01 15:37 UTC (permalink / raw)
To: Conor Dooley, Nicolas Ferre, Claudiu Beznea, Rob Herring,
Krzysztof Kozlowski, Lars Povlsen, Steen Hegelund, Daniel Machon,
UNGLinuxDriver, David S. Miller, Bjarni Jonasson,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401153740.123978-1-krzk@kernel.org>
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 <krzk@kernel.org>
---
.../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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 07/10] arm64: dts: microchip: sparx5_pcb134: drop LED unit addresses
From: Krzysztof Kozlowski @ 2024-04-01 15:37 UTC (permalink / raw)
To: Conor Dooley, Nicolas Ferre, Claudiu Beznea, Rob Herring,
Krzysztof Kozlowski, Lars Povlsen, Steen Hegelund, Daniel Machon,
UNGLinuxDriver, David S. Miller, Bjarni Jonasson,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401153740.123978-1-krzk@kernel.org>
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 <krzk@kernel.org>
---
.../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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 05/10] arm64: dts: microchip: sparx5_pcb134: align I2C mux node name with bindings
From: Krzysztof Kozlowski @ 2024-04-01 15:37 UTC (permalink / raw)
To: Conor Dooley, Nicolas Ferre, Claudiu Beznea, Rob Herring,
Krzysztof Kozlowski, Lars Povlsen, Steen Hegelund, Daniel Machon,
UNGLinuxDriver, David S. Miller, Bjarni Jonasson,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401153740.123978-1-krzk@kernel.org>
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 <krzk@kernel.org>
---
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 06/10] arm64: dts: microchip: sparx5_pcb135: align I2C mux node name with bindings
From: Krzysztof Kozlowski @ 2024-04-01 15:37 UTC (permalink / raw)
To: Conor Dooley, Nicolas Ferre, Claudiu Beznea, Rob Herring,
Krzysztof Kozlowski, Lars Povlsen, Steen Hegelund, Daniel Machon,
UNGLinuxDriver, David S. Miller, Bjarni Jonasson,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401153740.123978-1-krzk@kernel.org>
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 <krzk@kernel.org>
---
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 04/10] arm64: dts: microchip: sparx5_pcb135: add missing I2C mux unit addresses
From: Krzysztof Kozlowski @ 2024-04-01 15:37 UTC (permalink / raw)
To: Conor Dooley, Nicolas Ferre, Claudiu Beznea, Rob Herring,
Krzysztof Kozlowski, Lars Povlsen, Steen Hegelund, Daniel Machon,
UNGLinuxDriver, David S. Miller, Bjarni Jonasson,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401153740.123978-1-krzk@kernel.org>
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 <krzk@kernel.org>
---
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 03/10] arm64: dts: microchip: sparx5_pcb134: add missing I2C mux unit addresses
From: Krzysztof Kozlowski @ 2024-04-01 15:37 UTC (permalink / raw)
To: Conor Dooley, Nicolas Ferre, Claudiu Beznea, Rob Herring,
Krzysztof Kozlowski, Lars Povlsen, Steen Hegelund, Daniel Machon,
UNGLinuxDriver, David S. Miller, Bjarni Jonasson,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401153740.123978-1-krzk@kernel.org>
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 <krzk@kernel.org>
---
.../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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 02/10] arm64: dts: microchip: sparx5: correct serdes unit address
From: Krzysztof Kozlowski @ 2024-04-01 15:37 UTC (permalink / raw)
To: Conor Dooley, Nicolas Ferre, Claudiu Beznea, Rob Herring,
Krzysztof Kozlowski, Lars Povlsen, Steen Hegelund, Daniel Machon,
UNGLinuxDriver, David S. Miller, Bjarni Jonasson,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401153740.123978-1-krzk@kernel.org>
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 <krzk@kernel.org>
---
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] clk: nxp: Remove an unused field in struct lpc18xx_pll
From: Christophe JAILLET @ 2024-04-01 15:31 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Vladimir Zapolskiy
Cc: linux-kernel, kernel-janitors, Christophe JAILLET, linux-clk,
linux-arm-kernel
In "struct lpc18xx_pll", the 'lock' field is unused.
Remove it.
Found with cppcheck, unusedStructMember.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
Compile tested only.
---
drivers/clk/nxp/clk-lpc18xx-cgu.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/clk/nxp/clk-lpc18xx-cgu.c b/drivers/clk/nxp/clk-lpc18xx-cgu.c
index 69ebf65081b8..81efa885069b 100644
--- a/drivers/clk/nxp/clk-lpc18xx-cgu.c
+++ b/drivers/clk/nxp/clk-lpc18xx-cgu.c
@@ -250,7 +250,6 @@ static struct lpc18xx_cgu_base_clk lpc18xx_cgu_base_clks[] = {
struct lpc18xx_pll {
struct clk_hw hw;
void __iomem *reg;
- spinlock_t *lock;
u8 flags;
};
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] ath9k: use unmanaged PCI functions in ath9k_pci_owl_loader
From: Heiner Kallweit @ 2024-04-01 15:30 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Kalle Valo, Andreas Färber,
Manivannan Sadhasivam, Martin Blumenstingl
Cc: linux-wireless, linux-arm-kernel@lists.infradead.org,
linux-actions, linux-pci@vger.kernel.org
Using the device-managed versions has no benefit here, because
resources are released as part of the asynchronous fw loading.
Actual reason why I got here is that I was looking for places with
dubious use of pcim_pin_device().
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
index a5eb43f30..bc93ca075 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
+++ b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
@@ -65,7 +65,7 @@ static int ath9k_pci_fixup(struct pci_dev *pdev, const u16 *cal_data,
dev_info(&pdev->dev, "fixup device configuration\n");
- mem = pcim_iomap(pdev, 0, 0);
+ mem = pci_iomap(pdev, 0, 0);
if (!mem) {
dev_err(&pdev->dev, "ioremap error\n");
return -EINVAL;
@@ -103,7 +103,7 @@ static int ath9k_pci_fixup(struct pci_dev *pdev, const u16 *cal_data,
pci_write_config_word(pdev, PCI_COMMAND, cmd);
pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0, bar0);
- pcim_iounmap(pdev, mem);
+ pci_iounmap(pdev, mem);
pci_disable_device(pdev);
@@ -200,11 +200,9 @@ static int owl_probe(struct pci_dev *pdev,
const char *eeprom_name;
int err = 0;
- if (pcim_enable_device(pdev))
+ if (pci_enable_device(pdev))
return -EIO;
- pcim_pin_device(pdev);
-
ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: uniphier: ld20-global: use generic node name for audio-codec
From: Krzysztof Kozlowski @ 2024-04-01 14:09 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Kunihiko Hayashi,
Masami Hiramatsu, devicetree, linux-arm-kernel, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401140952.97923-1-krzk@kernel.org>
Devicetree specification expects node names to be generic, representing
the class of devices.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
index a01579cb3b79..a4c86137f424 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
@@ -111,7 +111,7 @@ &comp_spdif_hiecout1 {
&i2c0 {
status = "okay";
- tas5707@1b {
+ audio-codec@1b {
compatible = "ti,tas5711";
reg = <0x1b>;
reset-gpios = <&gpio UNIPHIER_GPIO_PORT(0, 0) GPIO_ACTIVE_LOW>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: realtek: rtc16xx: add missing unit address to soc node
From: Krzysztof Kozlowski @ 2024-04-01 14:09 UTC (permalink / raw)
To: Andreas Färber, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-kernel, linux-realtek-soc, devicetree,
linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401140912.97157-1-krzk@kernel.org>
"soc" node has "ranges" property thus add matching unit address to fix
dtc W=1 warnings:
rtd16xx.dtsi:130.6-198.4: Warning (unit_address_vs_reg): /soc: node has a reg or ranges property, but no unit name
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/realtek/rtd16xx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/realtek/rtd16xx.dtsi b/arch/arm64/boot/dts/realtek/rtd16xx.dtsi
index 34802cc62983..c10c7eaf1b03 100644
--- a/arch/arm64/boot/dts/realtek/rtd16xx.dtsi
+++ b/arch/arm64/boot/dts/realtek/rtd16xx.dtsi
@@ -127,7 +127,7 @@ osc27M: osc {
#clock-cells = <0>;
};
- soc {
+ soc@0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] ASoC: dt-bindings: mt2701-wm8960: Convert to dtschema
From: Rob Herring @ 2024-04-01 15:14 UTC (permalink / raw)
To: Kartik Agarwala
Cc: lgirdwood, broonie, krzysztof.kozlowski+dt, conor+dt,
matthias.bgg, angelogioacchino.delregno, linux-sound, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20240401043505.40972-1-agarwala.kartik@gmail.com>
On Mon, Apr 01, 2024 at 10:05:05AM +0530, Kartik Agarwala wrote:
> Convert mt2701-wm890 bindings from text to dtschema. This is used by MediaTek mt77623a/n SoC.
Wrap lines at 75.
>
> Signed-off-by: Kartik Agarwala <agarwala.kartik@gmail.com>
> ---
> .../sound/mediatek,mt2701-wm8960.yaml | 59 +++++++++++++++++++
> .../bindings/sound/mt2701-wm8960.txt | 24 --------
> 2 files changed, 59 insertions(+), 24 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml
> delete mode 100644 Documentation/devicetree/bindings/sound/mt2701-wm8960.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml
> new file mode 100644
> index 000000000..771f14a59
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml
> @@ -0,0 +1,59 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/mediatek,mt2701-wm8960.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MT2701 with WM8960 CODEC
> +
> +maintainers:
> + - Kartik Agarwala <agarwala.kartik@gmail.com>
> +
> +properties:
> + compatible:
> + const: mediatek,mt2701-wm8960-machine
> +
> + mediatek,platform:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: The phandle of MT2701 ASoC platform.
> +
> + audio-routing:
> + $ref: /schemas/types.yaml#/definitions/non-unique-string-array
> + description: |
Don't need '|'.
> + A list of the connections between audio components. Each entry is a
> + pair of strings, the first being the connection's sink, the second
> + being the connection's source.
> +
> + mediatek,audio-codec:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: The phandle of the WM8960 audio codec.
> +
> + pinctrl-names:
> + const: default
> +
> + pinctrl-0: true
You can drop pinctrl properties. Those are implicitly supported.
> +
> +unevaluatedProperties: false
> +
> +required:
> + - compatible
> + - mediatek,platform
> + - audio-routing
> + - mediatek,audio-codec
> + - pinctrl-names
> + - pinctrl-0
> +
> +examples:
> + - |
> + sound {
> + compatible = "mediatek,mt2701-wm8960-machine";
> + mediatek,platform = <&afe>;
> + audio-routing =
> + "Headphone", "HP_L",
> + "Headphone", "HP_R",
> + "LINPUT1", "AMIC",
> + "RINPUT1", "AMIC";
> + mediatek,audio-codec = <&wm8960>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&aud_pins_default>;
> + };
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: davinci: da850: fix selecting ARCH_DAVINCI_DA8XX
From: David Lechner @ 2024-04-01 15:09 UTC (permalink / raw)
To: Bartosz Golaszewski, Russell King, Arnd Bergmann
Cc: David Lechner, Bartosz Golaszewski, linux-arm-kernel,
linux-kernel
Chips in the DA850 family need to have ARCH_DAVINCI_DA8XX to be selected
in order to enable some peripheral drivers.
This was accidentally removed in a previous commit.
Fixes: dec85a95167a ("ARM: davinci: clean up platform support")
Signed-off-by: David Lechner <dlechner@baylibre.com>
---
arch/arm/mach-davinci/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 2a8a9fe46586..3fa15f342240 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -27,6 +27,7 @@ config ARCH_DAVINCI_DA830
config ARCH_DAVINCI_DA850
bool "DA850/OMAP-L138/AM18x based system"
+ select ARCH_DAVINCI_DA8XX
select DAVINCI_CP_INTC
config ARCH_DAVINCI_DA8XX
---
base-commit: 39cd87c4eb2b893354f3b850f916353f2658ae6f
change-id: 20240401-da850-fix-select-da8xx-989725eec11f
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 6/6] arm64: dts: marvell: cn9130-crb: drop unneeded "status"
From: Andrew Lunn @ 2024-04-01 14:53 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240401141051.98233-6-krzk@kernel.org>
On Mon, Apr 01, 2024 at 04:10:51PM +0200, Krzysztof Kozlowski wrote:
> Devices are enabled by default.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/6] arm64: dts: marvell: cn9130-crb: drop wrong unit-addresses
From: Andrew Lunn @ 2024-04-01 14:52 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240401141051.98233-5-krzk@kernel.org>
On Mon, Apr 01, 2024 at 04:10:50PM +0200, Krzysztof Kozlowski wrote:
> Top-level nodes, not being on MMIO bus, do not have "reg" properties and
> should not have unit addresses. Correct their name as well to match
> "Generic node names" recommendation from Devicetree specification.
> This also fixes dtc W=1 warnings:
>
> cn9130-crb.dtsi:29.35-37.4: Warning (unit_address_vs_reg): /ap0_mmc_vccq@0: node has a unit name, but no reg or ranges property
> cn9130-crb.dtsi:39.38-46.4: Warning (unit_address_vs_reg): /cp0_usb3_vbus@1: node has a unit name, but no reg or ranges property
> cn9130-crb.dtsi:57.33-65.4: Warning (unit_address_vs_reg): /cp0_sd_vccq@0: node has a unit name, but no reg or ranges property
> cn9130-crb.dtsi:67.31-75.4: Warning (unit_address_vs_reg): /cp0_sd_vcc@0: node has a unit name, but no reg or ranges property
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/6] arm64: dts: marvell: cn9130-db: drop wrong unit-addresses
From: Andrew Lunn @ 2024-04-01 14:52 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240401141051.98233-4-krzk@kernel.org>
On Mon, Apr 01, 2024 at 04:10:49PM +0200, Krzysztof Kozlowski wrote:
> Top-level nodes, not being on MMIO bus, do not have "reg" properties and
> should not have unit addresses. Correct their name as well to match
> "Generic node names" recommendation from Devicetree specification.
> This also fixes dtc W=1 warnings:
>
> cn9130-db.dtsi:28.11-31.4: Warning (unique_unit_address_if_enabled): /memory@0: duplicate unit-address (also used in node /ap0_sd_vccq@0)
> cn9130-db.dtsi:28.11-31.4: Warning (unique_unit_address_if_enabled): /memory@0: duplicate unit-address (also used in node /cp0_usb3_vbus@0)
> cn9130-db.dtsi:33.33-40.4: Warning (unique_unit_address_if_enabled): /ap0_sd_vccq@0: duplicate unit-address (also used in node /cp0_usb3_vbus@0)
> cn9130-db.dtsi:28.11-31.4: Warning (unique_unit_address_if_enabled): /memory@0: duplicate unit-address (also used in node /cp0_usb3_phy@0)
> cn9130-db.dtsi:33.33-40.4: Warning (unit_address_vs_reg): /ap0_sd_vccq@0: node has a unit name, but no reg or ranges property
> cn9130-db.dtsi:42.38-49.4: Warning (unit_address_vs_reg): /cp0_usb3_vbus@0: node has a unit name, but no reg or ranges property
> cn9130-db.dtsi:51.34-54.4: Warning (unit_address_vs_reg): /cp0_usb3_phy@0: node has a unit name, but no reg or ranges property
> cn9130-db.dtsi:56.38-63.4: Warning (unit_address_vs_reg): /cp0_usb3_vbus@1: node has a unit name, but no reg or ranges property
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/6] arm64: dts: marvell: cn9131-db: drop unneeded flash address/size-cells
From: Andrew Lunn @ 2024-04-01 14:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240401141051.98233-3-krzk@kernel.org>
On Mon, Apr 01, 2024 at 04:10:48PM +0200, Krzysztof Kozlowski wrote:
> Flash node uses single "partition" node to describe partitions, so
> remove deprecated address/size-cells properties to also fix dtc W=1
> warnings:
>
> cn9131-db.dtsi:140.10-163.4: Warning (avoid_unnecessary_addr_size): /cp1/config-space@f4000000/spi@700680/flash@0: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/6] arm64: dts: marvell: cn9130-db: drop unneeded flash address/size-cells
From: Andrew Lunn @ 2024-04-01 14:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240401141051.98233-2-krzk@kernel.org>
On Mon, Apr 01, 2024 at 04:10:47PM +0200, Krzysztof Kozlowski wrote:
> Flash node uses single "partition" node to describe partitions, so
> remove deprecated address/size-cells properties to also fix dtc W=1
> warnings:
>
> cn9130-db.dtsi:313.10-336.4: Warning (avoid_unnecessary_addr_size): /cp0/config-space@f2000000/spi@700680/flash@0: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/6] arm64: dts: marvell: ap80x: fix IOMMU unit address
From: Andrew Lunn @ 2024-04-01 14:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240401141051.98233-1-krzk@kernel.org>
On Mon, Apr 01, 2024 at 04:10:46PM +0200, Krzysztof Kozlowski wrote:
> Correct the IOMMU device node unit address to match "reg" and fix dtc
> W=1 warnings:
>
> armada-ap80x.dtsi:64.24-80.6: Warning (simple_bus_reg): /ap807/config-space@f0000000/iommu@5000000: simple-bus unit address format error, expected "100000"
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 3/6] dt-bindings: clock: meson: a1: peripherals: support sys_pll_div16 input
From: Rob Herring @ 2024-04-01 14:21 UTC (permalink / raw)
To: Dmitry Rokosov
Cc: neil.armstrong, jbrunet, mturquette, sboyd,
krzysztof.kozlowski+dt, khilman, martin.blumenstingl, kernel,
rockosov, linux-amlogic, linux-clk, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20240329205904.25002-4-ddrokosov@salutedevices.com>
On Fri, Mar 29, 2024 at 11:58:43PM +0300, Dmitry Rokosov wrote:
> The 'sys_pll_div16' input clock is used as one of the sources for the
> GEN clock.
>
> Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
> ---
> .../bindings/clock/amlogic,a1-peripherals-clkc.yaml | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/amlogic,a1-peripherals-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a1-peripherals-clkc.yaml
> index 6d84cee1bd75..f6668991ff1f 100644
> --- a/Documentation/devicetree/bindings/clock/amlogic,a1-peripherals-clkc.yaml
> +++ b/Documentation/devicetree/bindings/clock/amlogic,a1-peripherals-clkc.yaml
> @@ -29,6 +29,7 @@ properties:
> - description: input fixed pll div5
> - description: input fixed pll div7
> - description: input hifi pll
> + - description: input sys pll div16
> - description: input oscillator (usually at 24MHz)
>
> clock-names:
> @@ -38,6 +39,7 @@ properties:
> - const: fclk_div5
> - const: fclk_div7
> - const: hifi_pll
> + - const: sys_pll_div16
> - const: xtal
And adding an entry in the middle is also an ABI break. New entries go
on the end (and should be optional).
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 1/6] dt-bindings: clock: meson: a1: pll: introduce new syspll bindings
From: Rob Herring @ 2024-04-01 14:20 UTC (permalink / raw)
To: Dmitry Rokosov
Cc: neil.armstrong, jbrunet, mturquette, sboyd,
krzysztof.kozlowski+dt, khilman, martin.blumenstingl, kernel,
rockosov, linux-amlogic, linux-clk, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20240329205904.25002-2-ddrokosov@salutedevices.com>
On Fri, Mar 29, 2024 at 11:58:41PM +0300, Dmitry Rokosov wrote:
> The 'syspll' PLL is a general-purpose PLL designed specifically for the
> CPU clock. It is capable of producing output frequencies within the
> range of 768MHz to 1536MHz.
>
> Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
> ---
> .../devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml | 7 +++++--
> include/dt-bindings/clock/amlogic,a1-pll-clkc.h | 2 ++
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
> index a59b188a8bf5..fbba57031278 100644
> --- a/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
> +++ b/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
> @@ -26,11 +26,13 @@ properties:
> items:
> - description: input fixpll_in
> - description: input hifipll_in
> + - description: input syspll_in
>
> clock-names:
> items:
> - const: fixpll_in
> - const: hifipll_in
> + - const: syspll_in
A new required entry is an ABI break. Please state why that's ok or make
it optional (minItems: 2).
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] drm/mediatek: Perform iounmap on simple DDP component destruction
From: Chun-Kuang Hu @ 2024-04-01 14:18 UTC (permalink / raw)
To: CK Hu (胡俊光)
Cc: angelogioacchino.delregno@collabora.com, chunkuang.hu@kernel.org,
linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
wenst@chromium.org, kernel@collabora.com,
Nancy Lin (林欣螢), daniel@ffwll.ch,
p.zabel@pengutronix.de, dri-devel@lists.freedesktop.org,
Nathan Lu (呂東霖), airlied@gmail.com,
linux-arm-kernel@lists.infradead.org, matthias.bgg@gmail.com
In-Reply-To: <4b5d172c9b169313aaec777158e2db697fe447fc.camel@mediatek.com>
Hi, Angelo:
CK Hu (胡俊光) <ck.hu@mediatek.com> 於 2024年3月22日 週五 下午4:49寫道：
>
> Hi, Angelo:
>
> On Thu, 2024-02-01 at 13:53 +0100, AngeloGioacchino Del Regno wrote:
> > Add a new mtk_ddp_comp_destroy() function and call it in the teardown
> > path of mtk_drm_drv to make sure that we unmap the iospace of the
> > simple DDP components.
> >
> > While at it, also fix iounmapping on mtk_ddp_comp_init() error path.
>
> Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> >
> > Fixes: ff1395609e20 ("drm/mediatek: Move mtk_ddp_comp_init() from sub
> > driver to DRM driver")
> > Signed-off-by: AngeloGioacchino Del Regno <
> > angelogioacchino.delregno@collabora.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 38
> > ++++++++++++++++++++-
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 ++-
> > 3 files changed, 41 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > index c13359eeb3cd..539b526a6b0a 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > @@ -626,8 +626,11 @@ int mtk_ddp_comp_init(struct device_node *node,
> > struct mtk_ddp_comp *comp,
> >
> > priv->regs = of_iomap(node, 0);
> > priv->clk = of_clk_get(node, 0);
> > - if (IS_ERR(priv->clk))
> > + if (IS_ERR(priv->clk)) {
> > + iounmap(priv->regs);
> > + priv->regs = NULL;
> > return PTR_ERR(priv->clk);
> > + }
> >
> > #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> > ret = cmdq_dev_get_client_reg(comp->dev, &priv->cmdq_reg, 0);
> > @@ -639,3 +642,36 @@ int mtk_ddp_comp_init(struct device_node *node,
> > struct mtk_ddp_comp *comp,
> >
> > return 0;
> > }
> > +
> > +void mtk_ddp_comp_destroy(struct mtk_ddp_comp *comp)
> > +{
> > + struct mtk_ddp_comp_dev *priv;
> > +
> > + if (!comp || !comp->dev)
> > + return;
> > +
> > + /* Complex components are destroyed with their own remove
> > callback */
> > + if (type == MTK_DISP_AAL ||
Build error:
../drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c: In function
\u2018mtk_ddp_comp_destroy\u2019:
../drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c:657:13: error:
\u2018type\u2019 undeclared (first use in this function); did you mean
\u2018_ctype\u2019?
657 | if (type == MTK_DISP_AAL ||
| ^~~~
| _ctype
../drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c:657:13: note: each
undeclared identifier is reported only once for each function it
appears in
Regards,
Chun-Kuang.
> > + type == MTK_DISP_BLS ||
> > + type == MTK_DISP_CCORR ||
> > + type == MTK_DISP_COLOR ||
> > + type == MTK_DISP_GAMMA ||
> > + type == MTK_DISP_MERGE ||
> > + type == MTK_DISP_OVL ||
> > + type == MTK_DISP_OVL_2L ||
> > + type == MTK_DISP_PWM ||
> > + type == MTK_DISP_RDMA ||
> > + type == MTK_DPI ||
> > + type == MTK_DP_INTF ||
> > + type == MTK_DSI)
> > + return;
> > +
> > + priv = dev_get_drvdata(comp->dev);
> > + if (!priv)
> > + return;
> > +
> > + if (priv->regs) {
> > + iounmap(priv->regs);
> > + priv->regs = NULL;
> > + }
> > +}
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > index 15b2eafff438..43372b416a3f 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > @@ -318,6 +318,7 @@ unsigned int
> > mtk_drm_find_possible_crtc_by_comp(struct drm_device *drm,
> > struct device *dev);
> > int mtk_ddp_comp_init(struct device_node *comp_node, struct
> > mtk_ddp_comp *comp,
> > unsigned int comp_id);
> > +void mtk_ddp_comp_destroy(struct mtk_ddp_comp *comp);
> > enum mtk_ddp_comp_type mtk_ddp_comp_get_type(unsigned int comp_id);
> > void mtk_ddp_write(struct cmdq_pkt *cmdq_pkt, unsigned int value,
> > struct cmdq_client_reg *cmdq_reg, void __iomem
> > *regs,
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > index 14a1e0157cc4..89b6c31a1511 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > @@ -944,8 +944,10 @@ static void mtk_drm_remove(struct
> > platform_device *pdev)
> > component_master_del(&pdev->dev, &mtk_drm_ops);
> > pm_runtime_disable(&pdev->dev);
> > of_node_put(private->mutex_node);
> > - for (i = 0; i < DDP_COMPONENT_DRM_ID_MAX; i++)
> > + for (i = 0; i < DDP_COMPONENT_DRM_ID_MAX; i++) {
> > + mtk_ddp_comp_destroy(&private->ddp_comp[i]);
> > of_node_put(private->comp_node[i]);
> > + }
> > }
> >
> > static int mtk_drm_sys_prepare(struct device *dev)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 6/6] arm64: dts: marvell: cn9130-crb: drop unneeded "status"
From: Krzysztof Kozlowski @ 2024-04-01 14:10 UTC (permalink / raw)
To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401141051.98233-1-krzk@kernel.org>
Devices are enabled by default.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/marvell/cn9130-crb.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/marvell/cn9130-crb.dtsi b/arch/arm64/boot/dts/marvell/cn9130-crb.dtsi
index d48dd6bca6e5..5e7d6de3cdde 100644
--- a/arch/arm64/boot/dts/marvell/cn9130-crb.dtsi
+++ b/arch/arm64/boot/dts/marvell/cn9130-crb.dtsi
@@ -82,7 +82,6 @@ sfp: sfp {
tx-disable-gpios = <&expander0 2 GPIO_ACTIVE_HIGH>;
tx-fault-gpios = <&cp0_gpio1 24 GPIO_ACTIVE_HIGH>;
maximum-power-milliwatt = <3000>;
- status = "okay";
};
};
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 5/6] arm64: dts: marvell: cn9130-crb: drop wrong unit-addresses
From: Krzysztof Kozlowski @ 2024-04-01 14:10 UTC (permalink / raw)
To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401141051.98233-1-krzk@kernel.org>
Top-level nodes, not being on MMIO bus, do not have "reg" properties and
should not have unit addresses. Correct their name as well to match
"Generic node names" recommendation from Devicetree specification.
This also fixes dtc W=1 warnings:
cn9130-crb.dtsi:29.35-37.4: Warning (unit_address_vs_reg): /ap0_mmc_vccq@0: node has a unit name, but no reg or ranges property
cn9130-crb.dtsi:39.38-46.4: Warning (unit_address_vs_reg): /cp0_usb3_vbus@1: node has a unit name, but no reg or ranges property
cn9130-crb.dtsi:57.33-65.4: Warning (unit_address_vs_reg): /cp0_sd_vccq@0: node has a unit name, but no reg or ranges property
cn9130-crb.dtsi:67.31-75.4: Warning (unit_address_vs_reg): /cp0_sd_vcc@0: node has a unit name, but no reg or ranges property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/marvell/cn9130-crb.dtsi | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/cn9130-crb.dtsi b/arch/arm64/boot/dts/marvell/cn9130-crb.dtsi
index 6fcc34f7b464..d48dd6bca6e5 100644
--- a/arch/arm64/boot/dts/marvell/cn9130-crb.dtsi
+++ b/arch/arm64/boot/dts/marvell/cn9130-crb.dtsi
@@ -26,7 +26,7 @@ memory@0 {
reg = <0x0 0x0 0x0 0x80000000>;
};
- ap0_reg_mmc_vccq: ap0_mmc_vccq@0 {
+ ap0_reg_mmc_vccq: regulator-1 {
compatible = "regulator-gpio";
regulator-name = "ap0_mmc_vccq";
regulator-min-microvolt = <1800000>;
@@ -36,7 +36,7 @@ ap0_reg_mmc_vccq: ap0_mmc_vccq@0 {
3300000 0x0>;
};
- cp0_reg_usb3_vbus1: cp0_usb3_vbus@1 {
+ cp0_reg_usb3_vbus1: regulator-2 {
compatible = "regulator-fixed";
regulator-name = "cp0-xhci1-vbus";
regulator-min-microvolt = <5000000>;
@@ -45,16 +45,16 @@ cp0_reg_usb3_vbus1: cp0_usb3_vbus@1 {
gpio = <&expander0 8 GPIO_ACTIVE_HIGH>;
};
- cp0_usb3_0_phy0: cp0_usb3_phy0 {
+ cp0_usb3_0_phy0: usb-phy-1 {
compatible = "usb-nop-xceiv";
};
- cp0_usb3_0_phy1: cp0_usb3_phy1 {
+ cp0_usb3_0_phy1: usb-phy-2 {
compatible = "usb-nop-xceiv";
vcc-supply = <&cp0_reg_usb3_vbus1>;
};
- cp0_reg_sd_vccq: cp0_sd_vccq@0 {
+ cp0_reg_sd_vccq: regulator-3 {
compatible = "regulator-gpio";
regulator-name = "cp0_sd_vccq";
regulator-min-microvolt = <1800000>;
@@ -64,7 +64,7 @@ cp0_reg_sd_vccq: cp0_sd_vccq@0 {
3300000 0x0>;
};
- cp0_reg_sd_vcc: cp0_sd_vcc@0 {
+ cp0_reg_sd_vcc: regulator-4 {
compatible = "regulator-fixed";
regulator-name = "cp0_sd_vcc";
regulator-min-microvolt = <3300000>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/6] arm64: dts: marvell: cn9130-db: drop wrong unit-addresses
From: Krzysztof Kozlowski @ 2024-04-01 14:10 UTC (permalink / raw)
To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401141051.98233-1-krzk@kernel.org>
Top-level nodes, not being on MMIO bus, do not have "reg" properties and
should not have unit addresses. Correct their name as well to match
"Generic node names" recommendation from Devicetree specification.
This also fixes dtc W=1 warnings:
cn9130-db.dtsi:28.11-31.4: Warning (unique_unit_address_if_enabled): /memory@0: duplicate unit-address (also used in node /ap0_sd_vccq@0)
cn9130-db.dtsi:28.11-31.4: Warning (unique_unit_address_if_enabled): /memory@0: duplicate unit-address (also used in node /cp0_usb3_vbus@0)
cn9130-db.dtsi:33.33-40.4: Warning (unique_unit_address_if_enabled): /ap0_sd_vccq@0: duplicate unit-address (also used in node /cp0_usb3_vbus@0)
cn9130-db.dtsi:28.11-31.4: Warning (unique_unit_address_if_enabled): /memory@0: duplicate unit-address (also used in node /cp0_usb3_phy@0)
cn9130-db.dtsi:33.33-40.4: Warning (unit_address_vs_reg): /ap0_sd_vccq@0: node has a unit name, but no reg or ranges property
cn9130-db.dtsi:42.38-49.4: Warning (unit_address_vs_reg): /cp0_usb3_vbus@0: node has a unit name, but no reg or ranges property
cn9130-db.dtsi:51.34-54.4: Warning (unit_address_vs_reg): /cp0_usb3_phy@0: node has a unit name, but no reg or ranges property
cn9130-db.dtsi:56.38-63.4: Warning (unit_address_vs_reg): /cp0_usb3_vbus@1: node has a unit name, but no reg or ranges property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/marvell/cn9130-db.dtsi | 16 ++++++++--------
arch/arm64/boot/dts/marvell/cn9131-db.dtsi | 6 +++---
arch/arm64/boot/dts/marvell/cn9132-db.dtsi | 12 ++++++------
3 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/cn9130-db.dtsi b/arch/arm64/boot/dts/marvell/cn9130-db.dtsi
index 01d6645ddba7..be56a2336265 100644
--- a/arch/arm64/boot/dts/marvell/cn9130-db.dtsi
+++ b/arch/arm64/boot/dts/marvell/cn9130-db.dtsi
@@ -30,7 +30,7 @@ memory@0 {
reg = <0x0 0x0 0x0 0x80000000>;
};
- ap0_reg_sd_vccq: ap0_sd_vccq@0 {
+ ap0_reg_sd_vccq: regulator-1 {
compatible = "regulator-gpio";
regulator-name = "ap0_sd_vccq";
regulator-min-microvolt = <1800000>;
@@ -39,7 +39,7 @@ ap0_reg_sd_vccq: ap0_sd_vccq@0 {
states = <1800000 0x1 3300000 0x0>;
};
- cp0_reg_usb3_vbus0: cp0_usb3_vbus@0 {
+ cp0_reg_usb3_vbus0: regulator-2 {
compatible = "regulator-fixed";
regulator-name = "cp0-xhci0-vbus";
regulator-min-microvolt = <5000000>;
@@ -48,12 +48,12 @@ cp0_reg_usb3_vbus0: cp0_usb3_vbus@0 {
gpio = <&expander0 0 GPIO_ACTIVE_HIGH>;
};
- cp0_usb3_0_phy0: cp0_usb3_phy@0 {
+ cp0_usb3_0_phy0: usb-phy-1 {
compatible = "usb-nop-xceiv";
vcc-supply = <&cp0_reg_usb3_vbus0>;
};
- cp0_reg_usb3_vbus1: cp0_usb3_vbus@1 {
+ cp0_reg_usb3_vbus1: regulator-3 {
compatible = "regulator-fixed";
regulator-name = "cp0-xhci1-vbus";
regulator-min-microvolt = <5000000>;
@@ -62,12 +62,12 @@ cp0_reg_usb3_vbus1: cp0_usb3_vbus@1 {
gpio = <&expander0 1 GPIO_ACTIVE_HIGH>;
};
- cp0_usb3_0_phy1: cp0_usb3_phy@1 {
+ cp0_usb3_0_phy1: usb-phy-2 {
compatible = "usb-nop-xceiv";
vcc-supply = <&cp0_reg_usb3_vbus1>;
};
- cp0_reg_sd_vccq: cp0_sd_vccq@0 {
+ cp0_reg_sd_vccq: regulator-4 {
compatible = "regulator-gpio";
regulator-name = "cp0_sd_vccq";
regulator-min-microvolt = <1800000>;
@@ -77,7 +77,7 @@ cp0_reg_sd_vccq: cp0_sd_vccq@0 {
3300000 0x0>;
};
- cp0_reg_sd_vcc: cp0_sd_vcc@0 {
+ cp0_reg_sd_vcc: regulator-5 {
compatible = "regulator-fixed";
regulator-name = "cp0_sd_vcc";
regulator-min-microvolt = <3300000>;
@@ -87,7 +87,7 @@ cp0_reg_sd_vcc: cp0_sd_vcc@0 {
regulator-always-on;
};
- cp0_sfp_eth0: sfp-eth@0 {
+ cp0_sfp_eth0: sfp-eth-1 {
compatible = "sff,sfp";
i2c-bus = <&cp0_sfpp0_i2c>;
los-gpios = <&cp0_module_expander1 11 GPIO_ACTIVE_HIGH>;
diff --git a/arch/arm64/boot/dts/marvell/cn9131-db.dtsi b/arch/arm64/boot/dts/marvell/cn9131-db.dtsi
index 8f2523786cfb..ad7360c83048 100644
--- a/arch/arm64/boot/dts/marvell/cn9131-db.dtsi
+++ b/arch/arm64/boot/dts/marvell/cn9131-db.dtsi
@@ -18,7 +18,7 @@ aliases {
ethernet4 = &cp1_eth1;
};
- cp1_reg_usb3_vbus0: cp1_usb3_vbus@0 {
+ cp1_reg_usb3_vbus0: regulator-6 {
compatible = "regulator-fixed";
pinctrl-names = "default";
pinctrl-0 = <&cp1_xhci0_vbus_pins>;
@@ -29,12 +29,12 @@ cp1_reg_usb3_vbus0: cp1_usb3_vbus@0 {
gpio = <&cp1_gpio1 3 GPIO_ACTIVE_HIGH>;
};
- cp1_usb3_0_phy0: cp1_usb3_phy0 {
+ cp1_usb3_0_phy0: usb-phy-3 {
compatible = "usb-nop-xceiv";
vcc-supply = <&cp1_reg_usb3_vbus0>;
};
- cp1_sfp_eth1: sfp-eth1 {
+ cp1_sfp_eth1: sfp-eth-2 {
compatible = "sff,sfp";
i2c-bus = <&cp1_i2c0>;
los-gpios = <&cp1_gpio1 11 GPIO_ACTIVE_HIGH>;
diff --git a/arch/arm64/boot/dts/marvell/cn9132-db.dtsi b/arch/arm64/boot/dts/marvell/cn9132-db.dtsi
index 512a4fa2861e..e753cfdac697 100644
--- a/arch/arm64/boot/dts/marvell/cn9132-db.dtsi
+++ b/arch/arm64/boot/dts/marvell/cn9132-db.dtsi
@@ -17,7 +17,7 @@ aliases {
ethernet5 = &cp2_eth0;
};
- cp2_reg_usb3_vbus0: cp2_usb3_vbus@0 {
+ cp2_reg_usb3_vbus0: regulator-7 {
compatible = "regulator-fixed";
regulator-name = "cp2-xhci0-vbus";
regulator-min-microvolt = <5000000>;
@@ -26,12 +26,12 @@ cp2_reg_usb3_vbus0: cp2_usb3_vbus@0 {
gpio = <&cp2_gpio1 2 GPIO_ACTIVE_HIGH>;
};
- cp2_usb3_0_phy0: cp2_usb3_phy0 {
+ cp2_usb3_0_phy0: usb-phy-4 {
compatible = "usb-nop-xceiv";
vcc-supply = <&cp2_reg_usb3_vbus0>;
};
- cp2_reg_usb3_vbus1: cp2_usb3_vbus@1 {
+ cp2_reg_usb3_vbus1: regulator-8 {
compatible = "regulator-fixed";
regulator-name = "cp2-xhci1-vbus";
regulator-min-microvolt = <5000000>;
@@ -40,12 +40,12 @@ cp2_reg_usb3_vbus1: cp2_usb3_vbus@1 {
gpio = <&cp2_gpio1 3 GPIO_ACTIVE_HIGH>;
};
- cp2_usb3_0_phy1: cp2_usb3_phy1 {
+ cp2_usb3_0_phy1: usb-phy-5 {
compatible = "usb-nop-xceiv";
vcc-supply = <&cp2_reg_usb3_vbus1>;
};
- cp2_reg_sd_vccq: cp2_sd_vccq@0 {
+ cp2_reg_sd_vccq: regulator-9 {
compatible = "regulator-gpio";
regulator-name = "cp2_sd_vcc";
regulator-min-microvolt = <1800000>;
@@ -54,7 +54,7 @@ cp2_reg_sd_vccq: cp2_sd_vccq@0 {
states = <1800000 0x1 3300000 0x0>;
};
- cp2_sfp_eth0: sfp-eth0 {
+ cp2_sfp_eth0: sfp-eth-3 {
compatible = "sff,sfp";
i2c-bus = <&cp2_sfpp0_i2c>;
los-gpios = <&cp2_module_expander1 11 GPIO_ACTIVE_HIGH>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox