[PATCH v2 0/5] arm: dts: mt7623: relocate gmacs, mt7530 switch, and mux phy

[PATCH v2 0/5] arm: dts: mt7623: relocate gmacs, mt7530 switch, and mux phy

[arinc9.unal]

Γεια σας και πάλι!

I initially just wanted to submit the phy muxing patch for BPI-R2 but after
looking around the bindings, I decided to do a bit of a cleanup.

The main takeaway of the cleanup is that the MT7530 switch is actually a
part of the multi-chip module on the MT7623AI SoC. I'm moving the bindings
for this switch to mt7623a.dtsi so they don't need to be defined on every
device with this SoC. This should ease it up for supporting more devices
with MT7623AI SoC on mainline.

I don't know if there's a pin wired for interrupt. The switch is going to
work with polling for the time being. Folks from MediaTek, feel free to
fill me in on this.

I've tested phy muxing on my BPI-R2. DTs compile fine.

v2:
- Do not define phy-mode on mt7623.dtsi, it should be defined on the DTs
that call mt7623.dtsi instead.
- Use the labels for the MACs, remove them from under &eth on the DTs that
call mt7623.dtsi.
- Mention on the log of the forth patch that the interface name will change
from wan to eth1.

Arınç ÜNAL (5):
  arm: dts: mt7623: add gmacs to mt7623.dtsi
  arm: dts: mt7623: add mt7530 switch to mt7623a.dtsi
  arm: dts: mt7623: change mt7530 switch address
  arm: dts: mt7623: mux phy0 on Bananapi BPI-R2
  arm: dts: mt7623: enable flow control on port@6

 arch/arm/boot/dts/mt7623.dtsi                 | 12 +++
 arch/arm/boot/dts/mt7623a-rfb-emmc.dts        | 86 ++++++----------------
 arch/arm/boot/dts/mt7623a-rfb-nand.dts        | 86 ++++++----------------
 arch/arm/boot/dts/mt7623a.dtsi                | 75 +++++++++++++++++++
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 42 ++++++-----
 arch/arm/boot/dts/mt7623n-rfb-emmc.dts        | 37 +++++-----
 6 files changed, 170 insertions(+), 168 deletions(-)

[PATCH v2 0/5] arm: dts: mt7623: relocate gmacs, mt7530 switch, and mux phy

[arinc9.unal]

Γεια σας και πάλι!

I initially just wanted to submit the phy muxing patch for BPI-R2 but after
looking around the bindings, I decided to do a bit of a cleanup.

The main takeaway of the cleanup is that the MT7530 switch is actually a
part of the multi-chip module on the MT7623AI SoC. I'm moving the bindings
for this switch to mt7623a.dtsi so they don't need to be defined on every
device with this SoC. This should ease it up for supporting more devices
with MT7623AI SoC on mainline.

I don't know if there's a pin wired for interrupt. The switch is going to
work with polling for the time being. Folks from MediaTek, feel free to
fill me in on this.

I've tested phy muxing on my BPI-R2. DTs compile fine.

v2:
- Do not define phy-mode on mt7623.dtsi, it should be defined on the DTs
that call mt7623.dtsi instead.
- Use the labels for the MACs, remove them from under &eth on the DTs that
call mt7623.dtsi.
- Mention on the log of the forth patch that the interface name will change
from wan to eth1.

Arınç ÜNAL (5):
  arm: dts: mt7623: add gmacs to mt7623.dtsi
  arm: dts: mt7623: add mt7530 switch to mt7623a.dtsi
  arm: dts: mt7623: change mt7530 switch address
  arm: dts: mt7623: mux phy0 on Bananapi BPI-R2
  arm: dts: mt7623: enable flow control on port@6

 arch/arm/boot/dts/mt7623.dtsi                 | 12 +++
 arch/arm/boot/dts/mt7623a-rfb-emmc.dts        | 86 ++++++----------------
 arch/arm/boot/dts/mt7623a-rfb-nand.dts        | 86 ++++++----------------
 arch/arm/boot/dts/mt7623a.dtsi                | 75 +++++++++++++++++++
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 42 ++++++-----
 arch/arm/boot/dts/mt7623n-rfb-emmc.dts        | 37 +++++-----
 6 files changed, 170 insertions(+), 168 deletions(-)

[PATCH v2 0/5] arm: dts: mt7623: relocate gmacs, mt7530 switch, and mux phy

[arinc9.unal]

Γεια σας και πάλι!

I initially just wanted to submit the phy muxing patch for BPI-R2 but after
looking around the bindings, I decided to do a bit of a cleanup.

The main takeaway of the cleanup is that the MT7530 switch is actually a
part of the multi-chip module on the MT7623AI SoC. I'm moving the bindings
for this switch to mt7623a.dtsi so they don't need to be defined on every
device with this SoC. This should ease it up for supporting more devices
with MT7623AI SoC on mainline.

I don't know if there's a pin wired for interrupt. The switch is going to
work with polling for the time being. Folks from MediaTek, feel free to
fill me in on this.

I've tested phy muxing on my BPI-R2. DTs compile fine.

v2:
- Do not define phy-mode on mt7623.dtsi, it should be defined on the DTs
that call mt7623.dtsi instead.
- Use the labels for the MACs, remove them from under &eth on the DTs that
call mt7623.dtsi.
- Mention on the log of the forth patch that the interface name will change
from wan to eth1.

Arınç ÜNAL (5):
  arm: dts: mt7623: add gmacs to mt7623.dtsi
  arm: dts: mt7623: add mt7530 switch to mt7623a.dtsi
  arm: dts: mt7623: change mt7530 switch address
  arm: dts: mt7623: mux phy0 on Bananapi BPI-R2
  arm: dts: mt7623: enable flow control on port@6

 arch/arm/boot/dts/mt7623.dtsi                 | 12 +++
 arch/arm/boot/dts/mt7623a-rfb-emmc.dts        | 86 ++++++----------------
 arch/arm/boot/dts/mt7623a-rfb-nand.dts        | 86 ++++++----------------
 arch/arm/boot/dts/mt7623a.dtsi                | 75 +++++++++++++++++++
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 42 ++++++-----
 arch/arm/boot/dts/mt7623n-rfb-emmc.dts        | 37 +++++-----
 6 files changed, 170 insertions(+), 168 deletions(-)



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 1/5] arm: dts: mt7623: add gmacs to mt7623.dtsi

[arinc9.unal]

From: Arınç ÜNAL <arinc.unal@arinc9.com>

There are two gigabit MACs on the MT7623AI and MT7623NI SoCs. Add them to
mt7623.dtsi and adjust the DTs that call mt7623.dtsi.

Now that there are labels for the MACs, remove them from under &eth on the
DTs that call mt7623.dtsi. Remove the unnecessary mdio label from Bananapi
BPI-R2.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
 arch/arm/boot/dts/mt7623.dtsi                 | 12 +++++++
 arch/arm/boot/dts/mt7623a-rfb-emmc.dts        | 21 ++++++------
 arch/arm/boot/dts/mt7623a-rfb-nand.dts        | 21 ++++++------
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 23 +++++++------
 arch/arm/boot/dts/mt7623n-rfb-emmc.dts        | 32 +++++++++----------
 5 files changed, 58 insertions(+), 51 deletions(-)

diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index 25d31e40a553..2bc3c49dc3df 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -981,6 +981,18 @@ eth: ethernet@1b100000 {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		status = "disabled";
+
+		gmac0: mac@0 {
+			compatible = "mediatek,eth-mac";
+			reg = <0>;
+			status = "disabled";
+		};
+
+		gmac1: mac@1 {
+			compatible = "mediatek,eth-mac";
+			reg = <1>;
+			status = "disabled";
+		};
 	};
 
 	crypto: crypto@1b240000 {
diff --git a/arch/arm/boot/dts/mt7623a-rfb-emmc.dts b/arch/arm/boot/dts/mt7623a-rfb-emmc.dts
index e8b4b6d30d19..a64d68b6e165 100644
--- a/arch/arm/boot/dts/mt7623a-rfb-emmc.dts
+++ b/arch/arm/boot/dts/mt7623a-rfb-emmc.dts
@@ -112,20 +112,19 @@ &crypto {
 	status = "okay";
 };
 
-&eth {
+&gmac0 {
 	status = "okay";
+	phy-mode = "trgmii";
 
-	gmac0: mac@0 {
-		compatible = "mediatek,eth-mac";
-		reg = <0>;
-		phy-mode = "trgmii";
-
-		fixed-link {
-			speed = <1000>;
-			full-duplex;
-			pause;
-		};
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+		pause;
 	};
+};
+
+&eth {
+	status = "okay";
 
 	mdio-bus {
 		#address-cells = <1>;
diff --git a/arch/arm/boot/dts/mt7623a-rfb-nand.dts b/arch/arm/boot/dts/mt7623a-rfb-nand.dts
index 61f5da68d4b0..fac3ca0322c8 100644
--- a/arch/arm/boot/dts/mt7623a-rfb-nand.dts
+++ b/arch/arm/boot/dts/mt7623a-rfb-nand.dts
@@ -116,20 +116,19 @@ &crypto {
 	status = "okay";
 };
 
-&eth {
+&gmac0 {
 	status = "okay";
+	phy-mode = "trgmii";
 
-	gmac0: mac@0 {
-		compatible = "mediatek,eth-mac";
-		reg = <0>;
-		phy-mode = "trgmii";
-
-		fixed-link {
-			speed = <1000>;
-			full-duplex;
-			pause;
-		};
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+		pause;
 	};
+};
+
+&eth {
+	status = "okay";
 
 	mdio-bus {
 		#address-cells = <1>;
diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
index 5008115d2494..1e03a3de654f 100644
--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
@@ -171,22 +171,21 @@ dpi0_out: endpoint {
 	};
 };
 
-&eth {
+&gmac0 {
 	status = "okay";
+	phy-mode = "trgmii";
 
-	gmac0: mac@0 {
-		compatible = "mediatek,eth-mac";
-		reg = <0>;
-		phy-mode = "trgmii";
-
-		fixed-link {
-			speed = <1000>;
-			full-duplex;
-			pause;
-		};
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+		pause;
 	};
+};
+
+&eth {
+	status = "okay";
 
-	mdio: mdio-bus {
+	mdio-bus {
 		#address-cells = <1>;
 		#size-cells = <0>;
 
diff --git a/arch/arm/boot/dts/mt7623n-rfb-emmc.dts b/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
index bf67a8e9be59..5e328c2a6a6e 100644
--- a/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
+++ b/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
@@ -156,27 +156,25 @@ dpi0_out: endpoint {
 	};
 };
 
-&eth {
+&gmac0 {
 	status = "okay";
+	phy-mode = "trgmii";
 
-	gmac0: mac@0 {
-		compatible = "mediatek,eth-mac";
-		reg = <0>;
-		phy-mode = "trgmii";
-
-		fixed-link {
-			speed = <1000>;
-			full-duplex;
-			pause;
-		};
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+		pause;
 	};
+};
 
-	mac@1 {
-		compatible = "mediatek,eth-mac";
-		reg = <1>;
-		phy-mode = "rgmii";
-		phy-handle = <&phy5>;
-	};
+&gmac1 {
+	status = "okay";
+	phy-mode = "rgmii";
+	phy-handle = <&phy5>;
+};
+
+&eth {
+	status = "okay";
 
 	mdio-bus {
 		#address-cells = <1>;
-- 
2.37.2

[PATCH v2 1/5] arm: dts: mt7623: add gmacs to mt7623.dtsi

[arinc9.unal]

From: Arınç ÜNAL <arinc.unal@arinc9.com>

There are two gigabit MACs on the MT7623AI and MT7623NI SoCs. Add them to
mt7623.dtsi and adjust the DTs that call mt7623.dtsi.

Now that there are labels for the MACs, remove them from under &eth on the
DTs that call mt7623.dtsi. Remove the unnecessary mdio label from Bananapi
BPI-R2.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
 arch/arm/boot/dts/mt7623.dtsi                 | 12 +++++++
 arch/arm/boot/dts/mt7623a-rfb-emmc.dts        | 21 ++++++------
 arch/arm/boot/dts/mt7623a-rfb-nand.dts        | 21 ++++++------
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 23 +++++++------
 arch/arm/boot/dts/mt7623n-rfb-emmc.dts        | 32 +++++++++----------
 5 files changed, 58 insertions(+), 51 deletions(-)

diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index 25d31e40a553..2bc3c49dc3df 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -981,6 +981,18 @@ eth: ethernet@1b100000 {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		status = "disabled";
+
+		gmac0: mac@0 {
+			compatible = "mediatek,eth-mac";
+			reg = <0>;
+			status = "disabled";
+		};
+
+		gmac1: mac@1 {
+			compatible = "mediatek,eth-mac";
+			reg = <1>;
+			status = "disabled";
+		};
 	};
 
 	crypto: crypto@1b240000 {
diff --git a/arch/arm/boot/dts/mt7623a-rfb-emmc.dts b/arch/arm/boot/dts/mt7623a-rfb-emmc.dts
index e8b4b6d30d19..a64d68b6e165 100644
--- a/arch/arm/boot/dts/mt7623a-rfb-emmc.dts
+++ b/arch/arm/boot/dts/mt7623a-rfb-emmc.dts
@@ -112,20 +112,19 @@ &crypto {
 	status = "okay";
 };
 
-&eth {
+&gmac0 {
 	status = "okay";
+	phy-mode = "trgmii";
 
-	gmac0: mac@0 {
-		compatible = "mediatek,eth-mac";
-		reg = <0>;
-		phy-mode = "trgmii";
-
-		fixed-link {
-			speed = <1000>;
-			full-duplex;
-			pause;
-		};
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+		pause;
 	};
+};
+
+&eth {
+	status = "okay";
 
 	mdio-bus {
 		#address-cells = <1>;
diff --git a/arch/arm/boot/dts/mt7623a-rfb-nand.dts b/arch/arm/boot/dts/mt7623a-rfb-nand.dts
index 61f5da68d4b0..fac3ca0322c8 100644
--- a/arch/arm/boot/dts/mt7623a-rfb-nand.dts
+++ b/arch/arm/boot/dts/mt7623a-rfb-nand.dts
@@ -116,20 +116,19 @@ &crypto {
 	status = "okay";
 };
 
-&eth {
+&gmac0 {
 	status = "okay";
+	phy-mode = "trgmii";
 
-	gmac0: mac@0 {
-		compatible = "mediatek,eth-mac";
-		reg = <0>;
-		phy-mode = "trgmii";
-
-		fixed-link {
-			speed = <1000>;
-			full-duplex;
-			pause;
-		};
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+		pause;
 	};
+};
+
+&eth {
+	status = "okay";
 
 	mdio-bus {
 		#address-cells = <1>;
diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
index 5008115d2494..1e03a3de654f 100644
--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
@@ -171,22 +171,21 @@ dpi0_out: endpoint {
 	};
 };
 
-&eth {
+&gmac0 {
 	status = "okay";
+	phy-mode = "trgmii";
 
-	gmac0: mac@0 {
-		compatible = "mediatek,eth-mac";
-		reg = <0>;
-		phy-mode = "trgmii";
-
-		fixed-link {
-			speed = <1000>;
-			full-duplex;
-			pause;
-		};
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+		pause;
 	};
+};
+
+&eth {
+	status = "okay";
 
-	mdio: mdio-bus {
+	mdio-bus {
 		#address-cells = <1>;
 		#size-cells = <0>;
 
diff --git a/arch/arm/boot/dts/mt7623n-rfb-emmc.dts b/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
index bf67a8e9be59..5e328c2a6a6e 100644
--- a/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
+++ b/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
@@ -156,27 +156,25 @@ dpi0_out: endpoint {
 	};
 };
 
-&eth {
+&gmac0 {
 	status = "okay";
+	phy-mode = "trgmii";
 
-	gmac0: mac@0 {
-		compatible = "mediatek,eth-mac";
-		reg = <0>;
-		phy-mode = "trgmii";
-
-		fixed-link {
-			speed = <1000>;
-			full-duplex;
-			pause;
-		};
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+		pause;
 	};
+};
 
-	mac@1 {
-		compatible = "mediatek,eth-mac";
-		reg = <1>;
-		phy-mode = "rgmii";
-		phy-handle = <&phy5>;
-	};
+&gmac1 {
+	status = "okay";
+	phy-mode = "rgmii";
+	phy-handle = <&phy5>;
+};
+
+&eth {
+	status = "okay";
 
 	mdio-bus {
 		#address-cells = <1>;
-- 
2.37.2

[PATCH v2 1/5] arm: dts: mt7623: add gmacs to mt7623.dtsi

[arinc9.unal]

From: Arınç ÜNAL <arinc.unal@arinc9.com>

There are two gigabit MACs on the MT7623AI and MT7623NI SoCs. Add them to
mt7623.dtsi and adjust the DTs that call mt7623.dtsi.

Now that there are labels for the MACs, remove them from under &eth on the
DTs that call mt7623.dtsi. Remove the unnecessary mdio label from Bananapi
BPI-R2.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
 arch/arm/boot/dts/mt7623.dtsi                 | 12 +++++++
 arch/arm/boot/dts/mt7623a-rfb-emmc.dts        | 21 ++++++------
 arch/arm/boot/dts/mt7623a-rfb-nand.dts        | 21 ++++++------
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 23 +++++++------
 arch/arm/boot/dts/mt7623n-rfb-emmc.dts        | 32 +++++++++----------
 5 files changed, 58 insertions(+), 51 deletions(-)

diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index 25d31e40a553..2bc3c49dc3df 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -981,6 +981,18 @@ eth: ethernet@1b100000 {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		status = "disabled";
+
+		gmac0: mac@0 {
+			compatible = "mediatek,eth-mac";
+			reg = <0>;
+			status = "disabled";
+		};
+
+		gmac1: mac@1 {
+			compatible = "mediatek,eth-mac";
+			reg = <1>;
+			status = "disabled";
+		};
 	};
 
 	crypto: crypto@1b240000 {
diff --git a/arch/arm/boot/dts/mt7623a-rfb-emmc.dts b/arch/arm/boot/dts/mt7623a-rfb-emmc.dts
index e8b4b6d30d19..a64d68b6e165 100644
--- a/arch/arm/boot/dts/mt7623a-rfb-emmc.dts
+++ b/arch/arm/boot/dts/mt7623a-rfb-emmc.dts
@@ -112,20 +112,19 @@ &crypto {
 	status = "okay";
 };
 
-&eth {
+&gmac0 {
 	status = "okay";
+	phy-mode = "trgmii";
 
-	gmac0: mac@0 {
-		compatible = "mediatek,eth-mac";
-		reg = <0>;
-		phy-mode = "trgmii";
-
-		fixed-link {
-			speed = <1000>;
-			full-duplex;
-			pause;
-		};
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+		pause;
 	};
+};
+
+&eth {
+	status = "okay";
 
 	mdio-bus {
 		#address-cells = <1>;
diff --git a/arch/arm/boot/dts/mt7623a-rfb-nand.dts b/arch/arm/boot/dts/mt7623a-rfb-nand.dts
index 61f5da68d4b0..fac3ca0322c8 100644
--- a/arch/arm/boot/dts/mt7623a-rfb-nand.dts
+++ b/arch/arm/boot/dts/mt7623a-rfb-nand.dts
@@ -116,20 +116,19 @@ &crypto {
 	status = "okay";
 };
 
-&eth {
+&gmac0 {
 	status = "okay";
+	phy-mode = "trgmii";
 
-	gmac0: mac@0 {
-		compatible = "mediatek,eth-mac";
-		reg = <0>;
-		phy-mode = "trgmii";
-
-		fixed-link {
-			speed = <1000>;
-			full-duplex;
-			pause;
-		};
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+		pause;
 	};
+};
+
+&eth {
+	status = "okay";
 
 	mdio-bus {
 		#address-cells = <1>;
diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
index 5008115d2494..1e03a3de654f 100644
--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
@@ -171,22 +171,21 @@ dpi0_out: endpoint {
 	};
 };
 
-&eth {
+&gmac0 {
 	status = "okay";
+	phy-mode = "trgmii";
 
-	gmac0: mac@0 {
-		compatible = "mediatek,eth-mac";
-		reg = <0>;
-		phy-mode = "trgmii";
-
-		fixed-link {
-			speed = <1000>;
-			full-duplex;
-			pause;
-		};
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+		pause;
 	};
+};
+
+&eth {
+	status = "okay";
 
-	mdio: mdio-bus {
+	mdio-bus {
 		#address-cells = <1>;
 		#size-cells = <0>;
 
diff --git a/arch/arm/boot/dts/mt7623n-rfb-emmc.dts b/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
index bf67a8e9be59..5e328c2a6a6e 100644
--- a/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
+++ b/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
@@ -156,27 +156,25 @@ dpi0_out: endpoint {
 	};
 };
 
-&eth {
+&gmac0 {
 	status = "okay";
+	phy-mode = "trgmii";
 
-	gmac0: mac@0 {
-		compatible = "mediatek,eth-mac";
-		reg = <0>;
-		phy-mode = "trgmii";
-
-		fixed-link {
-			speed = <1000>;
-			full-duplex;
-			pause;
-		};
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+		pause;
 	};
+};
 
-	mac@1 {
-		compatible = "mediatek,eth-mac";
-		reg = <1>;
-		phy-mode = "rgmii";
-		phy-handle = <&phy5>;
-	};
+&gmac1 {
+	status = "okay";
+	phy-mode = "rgmii";
+	phy-handle = <&phy5>;
+};
+
+&eth {
+	status = "okay";
 
 	mdio-bus {
 		#address-cells = <1>;
-- 
2.37.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 2/5] arm: dts: mt7623: add mt7530 switch to mt7623a.dtsi

[arinc9.unal]

From: Arınç ÜNAL <arinc.unal@arinc9.com>

The MT7530 switch is included as a part of the multi-chip module on the
MT7623AI SoC. Add it to mt7623a.dtsi and adjust DTs that call mt7623a.dtsi.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
 arch/arm/boot/dts/mt7623a-rfb-emmc.dts | 87 +++++++-------------------
 arch/arm/boot/dts/mt7623a-rfb-nand.dts | 87 +++++++-------------------
 arch/arm/boot/dts/mt7623a.dtsi         | 74 ++++++++++++++++++++++
 3 files changed, 118 insertions(+), 130 deletions(-)

diff --git a/arch/arm/boot/dts/mt7623a-rfb-emmc.dts b/arch/arm/boot/dts/mt7623a-rfb-emmc.dts
index a64d68b6e165..5654284bab01 100644
--- a/arch/arm/boot/dts/mt7623a-rfb-emmc.dts
+++ b/arch/arm/boot/dts/mt7623a-rfb-emmc.dts
@@ -112,74 +112,31 @@ &crypto {
 	status = "okay";
 };
 
-&gmac0 {
-	status = "okay";
-	phy-mode = "trgmii";
+&switch0 {
+	ports {
+		port@0 {
+			status = "okay";
+			label = "lan0";
+		};
 
-	fixed-link {
-		speed = <1000>;
-		full-duplex;
-		pause;
-	};
-};
+		port@1 {
+			status = "okay";
+			label = "lan1";
+		};
 
-&eth {
-	status = "okay";
+		port@2 {
+			status = "okay";
+			label = "lan2";
+		};
+
+		port@3 {
+			status = "okay";
+			label = "lan3";
+		};
 
-	mdio-bus {
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		switch@0 {
-			compatible = "mediatek,mt7530";
-			reg = <0>;
-			mediatek,mcm;
-			resets = <&ethsys MT2701_ETHSYS_MCM_RST>;
-			reset-names = "mcm";
-			core-supply = <&mt6323_vpa_reg>;
-			io-supply = <&mt6323_vemc3v3_reg>;
-
-			ports {
-				#address-cells = <1>;
-				#size-cells = <0>;
-
-				port@0 {
-					reg = <0>;
-					label = "lan0";
-				};
-
-				port@1 {
-					reg = <1>;
-					label = "lan1";
-				};
-
-				port@2 {
-					reg = <2>;
-					label = "lan2";
-				};
-
-				port@3 {
-					reg = <3>;
-					label = "lan3";
-				};
-
-				port@4 {
-					reg = <4>;
-					label = "wan";
-				};
-
-				port@6 {
-					reg = <6>;
-					label = "cpu";
-					ethernet = <&gmac0>;
-					phy-mode = "trgmii";
-
-					fixed-link {
-						speed = <1000>;
-						full-duplex;
-					};
-				};
-			};
+		port@4 {
+			status = "okay";
+			label = "wan";
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/mt7623a-rfb-nand.dts b/arch/arm/boot/dts/mt7623a-rfb-nand.dts
index fac3ca0322c8..afd177b3b516 100644
--- a/arch/arm/boot/dts/mt7623a-rfb-nand.dts
+++ b/arch/arm/boot/dts/mt7623a-rfb-nand.dts
@@ -116,74 +116,31 @@ &crypto {
 	status = "okay";
 };
 
-&gmac0 {
-	status = "okay";
-	phy-mode = "trgmii";
+&switch0 {
+	ports {
+		port@0 {
+			status = "okay";
+			label = "lan0";
+		};
 
-	fixed-link {
-		speed = <1000>;
-		full-duplex;
-		pause;
-	};
-};
+		port@1 {
+			status = "okay";
+			label = "lan1";
+		};
 
-&eth {
-	status = "okay";
+		port@2 {
+			status = "okay";
+			label = "lan2";
+		};
 
-	mdio-bus {
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		switch@0 {
-			compatible = "mediatek,mt7530";
-			reg = <0>;
-			mediatek,mcm;
-			resets = <&ethsys MT2701_ETHSYS_MCM_RST>;
-			reset-names = "mcm";
-			core-supply = <&mt6323_vpa_reg>;
-			io-supply = <&mt6323_vemc3v3_reg>;
-
-			ports {
-				#address-cells = <1>;
-				#size-cells = <0>;
-
-				port@0 {
-					reg = <0>;
-					label = "lan0";
-				};
-
-				port@1 {
-					reg = <1>;
-					label = "lan1";
-				};
-
-				port@2 {
-					reg = <2>;
-					label = "lan2";
-				};
-
-				port@3 {
-					reg = <3>;
-					label = "lan3";
-				};
-
-				port@4 {
-					reg = <4>;
-					label = "wan";
-				};
-
-				port@6 {
-					reg = <6>;
-					label = "cpu";
-					ethernet = <&gmac0>;
-					phy-mode = "trgmii";
-
-					fixed-link {
-						speed = <1000>;
-						full-duplex;
-					};
-				};
-			};
+		port@3 {
+			status = "okay";
+			label = "lan3";
+		};
+
+		port@4 {
+			status = "okay";
+			label = "wan";
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/mt7623a.dtsi b/arch/arm/boot/dts/mt7623a.dtsi
index d304b62d24b5..fbb5731a3a53 100644
--- a/arch/arm/boot/dts/mt7623a.dtsi
+++ b/arch/arm/boot/dts/mt7623a.dtsi
@@ -17,8 +17,82 @@ &crypto {
 	power-domains = <&scpsys MT7623A_POWER_DOMAIN_ETH>;
 };
 
+&gmac0 {
+	status = "okay";
+	phy-mode = "trgmii";
+
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+		pause;
+	};
+};
+
 &eth {
+	status = "okay";
 	power-domains = <&scpsys MT7623A_POWER_DOMAIN_ETH>;
+
+	mdio: mdio-bus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		switch0: switch@0 {
+			compatible = "mediatek,mt7530";
+			reg = <0>;
+			mediatek,mcm;
+			resets = <&ethsys MT2701_ETHSYS_MCM_RST>;
+			reset-names = "mcm";
+			core-supply = <&mt6323_vpa_reg>;
+			io-supply = <&mt6323_vemc3v3_reg>;
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					status = "disabled";
+					reg = <0>;
+					label = "swp0";
+				};
+
+				port@1 {
+					status = "disabled";
+					reg = <1>;
+					label = "swp1";
+				};
+
+				port@2 {
+					status = "disabled";
+					reg = <2>;
+					label = "swp2";
+				};
+
+				port@3 {
+					status = "disabled";
+					reg = <3>;
+					label = "swp3";
+				};
+
+				port@4 {
+					status = "disabled";
+					reg = <4>;
+					label = "swp4";
+				};
+
+				port@6 {
+					reg = <6>;
+					label = "cpu";
+					ethernet = <&gmac0>;
+					phy-mode = "trgmii";
+
+					fixed-link {
+						speed = <1000>;
+						full-duplex;
+					};
+				};
+			};
+		};
+	};
 };
 
 &nandc {
-- 
2.37.2

[PATCH v2 2/5] arm: dts: mt7623: add mt7530 switch to mt7623a.dtsi

[arinc9.unal]

From: Arınç ÜNAL <arinc.unal@arinc9.com>

The MT7530 switch is included as a part of the multi-chip module on the
MT7623AI SoC. Add it to mt7623a.dtsi and adjust DTs that call mt7623a.dtsi.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
 arch/arm/boot/dts/mt7623a-rfb-emmc.dts | 87 +++++++-------------------
 arch/arm/boot/dts/mt7623a-rfb-nand.dts | 87 +++++++-------------------
 arch/arm/boot/dts/mt7623a.dtsi         | 74 ++++++++++++++++++++++
 3 files changed, 118 insertions(+), 130 deletions(-)

diff --git a/arch/arm/boot/dts/mt7623a-rfb-emmc.dts b/arch/arm/boot/dts/mt7623a-rfb-emmc.dts
index a64d68b6e165..5654284bab01 100644
--- a/arch/arm/boot/dts/mt7623a-rfb-emmc.dts
+++ b/arch/arm/boot/dts/mt7623a-rfb-emmc.dts
@@ -112,74 +112,31 @@ &crypto {
 	status = "okay";
 };
 
-&gmac0 {
-	status = "okay";
-	phy-mode = "trgmii";
+&switch0 {
+	ports {
+		port@0 {
+			status = "okay";
+			label = "lan0";
+		};
 
-	fixed-link {
-		speed = <1000>;
-		full-duplex;
-		pause;
-	};
-};
+		port@1 {
+			status = "okay";
+			label = "lan1";
+		};
 
-&eth {
-	status = "okay";
+		port@2 {
+			status = "okay";
+			label = "lan2";
+		};
+
+		port@3 {
+			status = "okay";
+			label = "lan3";
+		};
 
-	mdio-bus {
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		switch@0 {
-			compatible = "mediatek,mt7530";
-			reg = <0>;
-			mediatek,mcm;
-			resets = <&ethsys MT2701_ETHSYS_MCM_RST>;
-			reset-names = "mcm";
-			core-supply = <&mt6323_vpa_reg>;
-			io-supply = <&mt6323_vemc3v3_reg>;
-
-			ports {
-				#address-cells = <1>;
-				#size-cells = <0>;
-
-				port@0 {
-					reg = <0>;
-					label = "lan0";
-				};
-
-				port@1 {
-					reg = <1>;
-					label = "lan1";
-				};
-
-				port@2 {
-					reg = <2>;
-					label = "lan2";
-				};
-
-				port@3 {
-					reg = <3>;
-					label = "lan3";
-				};
-
-				port@4 {
-					reg = <4>;
-					label = "wan";
-				};
-
-				port@6 {
-					reg = <6>;
-					label = "cpu";
-					ethernet = <&gmac0>;
-					phy-mode = "trgmii";
-
-					fixed-link {
-						speed = <1000>;
-						full-duplex;
-					};
-				};
-			};
+		port@4 {
+			status = "okay";
+			label = "wan";
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/mt7623a-rfb-nand.dts b/arch/arm/boot/dts/mt7623a-rfb-nand.dts
index fac3ca0322c8..afd177b3b516 100644
--- a/arch/arm/boot/dts/mt7623a-rfb-nand.dts
+++ b/arch/arm/boot/dts/mt7623a-rfb-nand.dts
@@ -116,74 +116,31 @@ &crypto {
 	status = "okay";
 };
 
-&gmac0 {
-	status = "okay";
-	phy-mode = "trgmii";
+&switch0 {
+	ports {
+		port@0 {
+			status = "okay";
+			label = "lan0";
+		};
 
-	fixed-link {
-		speed = <1000>;
-		full-duplex;
-		pause;
-	};
-};
+		port@1 {
+			status = "okay";
+			label = "lan1";
+		};
 
-&eth {
-	status = "okay";
+		port@2 {
+			status = "okay";
+			label = "lan2";
+		};
 
-	mdio-bus {
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		switch@0 {
-			compatible = "mediatek,mt7530";
-			reg = <0>;
-			mediatek,mcm;
-			resets = <&ethsys MT2701_ETHSYS_MCM_RST>;
-			reset-names = "mcm";
-			core-supply = <&mt6323_vpa_reg>;
-			io-supply = <&mt6323_vemc3v3_reg>;
-
-			ports {
-				#address-cells = <1>;
-				#size-cells = <0>;
-
-				port@0 {
-					reg = <0>;
-					label = "lan0";
-				};
-
-				port@1 {
-					reg = <1>;
-					label = "lan1";
-				};
-
-				port@2 {
-					reg = <2>;
-					label = "lan2";
-				};
-
-				port@3 {
-					reg = <3>;
-					label = "lan3";
-				};
-
-				port@4 {
-					reg = <4>;
-					label = "wan";
-				};
-
-				port@6 {
-					reg = <6>;
-					label = "cpu";
-					ethernet = <&gmac0>;
-					phy-mode = "trgmii";
-
-					fixed-link {
-						speed = <1000>;
-						full-duplex;
-					};
-				};
-			};
+		port@3 {
+			status = "okay";
+			label = "lan3";
+		};
+
+		port@4 {
+			status = "okay";
+			label = "wan";
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/mt7623a.dtsi b/arch/arm/boot/dts/mt7623a.dtsi
index d304b62d24b5..fbb5731a3a53 100644
--- a/arch/arm/boot/dts/mt7623a.dtsi
+++ b/arch/arm/boot/dts/mt7623a.dtsi
@@ -17,8 +17,82 @@ &crypto {
 	power-domains = <&scpsys MT7623A_POWER_DOMAIN_ETH>;
 };
 
+&gmac0 {
+	status = "okay";
+	phy-mode = "trgmii";
+
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+		pause;
+	};
+};
+
 &eth {
+	status = "okay";
 	power-domains = <&scpsys MT7623A_POWER_DOMAIN_ETH>;
+
+	mdio: mdio-bus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		switch0: switch@0 {
+			compatible = "mediatek,mt7530";
+			reg = <0>;
+			mediatek,mcm;
+			resets = <&ethsys MT2701_ETHSYS_MCM_RST>;
+			reset-names = "mcm";
+			core-supply = <&mt6323_vpa_reg>;
+			io-supply = <&mt6323_vemc3v3_reg>;
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					status = "disabled";
+					reg = <0>;
+					label = "swp0";
+				};
+
+				port@1 {
+					status = "disabled";
+					reg = <1>;
+					label = "swp1";
+				};
+
+				port@2 {
+					status = "disabled";
+					reg = <2>;
+					label = "swp2";
+				};
+
+				port@3 {
+					status = "disabled";
+					reg = <3>;
+					label = "swp3";
+				};
+
+				port@4 {
+					status = "disabled";
+					reg = <4>;
+					label = "swp4";
+				};
+
+				port@6 {
+					reg = <6>;
+					label = "cpu";
+					ethernet = <&gmac0>;
+					phy-mode = "trgmii";
+
+					fixed-link {
+						speed = <1000>;
+						full-duplex;
+					};
+				};
+			};
+		};
+	};
 };
 
 &nandc {
-- 
2.37.2

[PATCH v2 2/5] arm: dts: mt7623: add mt7530 switch to mt7623a.dtsi

[arinc9.unal]

From: Arınç ÜNAL <arinc.unal@arinc9.com>

The MT7530 switch is included as a part of the multi-chip module on the
MT7623AI SoC. Add it to mt7623a.dtsi and adjust DTs that call mt7623a.dtsi.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
 arch/arm/boot/dts/mt7623a-rfb-emmc.dts | 87 +++++++-------------------
 arch/arm/boot/dts/mt7623a-rfb-nand.dts | 87 +++++++-------------------
 arch/arm/boot/dts/mt7623a.dtsi         | 74 ++++++++++++++++++++++
 3 files changed, 118 insertions(+), 130 deletions(-)

diff --git a/arch/arm/boot/dts/mt7623a-rfb-emmc.dts b/arch/arm/boot/dts/mt7623a-rfb-emmc.dts
index a64d68b6e165..5654284bab01 100644
--- a/arch/arm/boot/dts/mt7623a-rfb-emmc.dts
+++ b/arch/arm/boot/dts/mt7623a-rfb-emmc.dts
@@ -112,74 +112,31 @@ &crypto {
 	status = "okay";
 };
 
-&gmac0 {
-	status = "okay";
-	phy-mode = "trgmii";
+&switch0 {
+	ports {
+		port@0 {
+			status = "okay";
+			label = "lan0";
+		};
 
-	fixed-link {
-		speed = <1000>;
-		full-duplex;
-		pause;
-	};
-};
+		port@1 {
+			status = "okay";
+			label = "lan1";
+		};
 
-&eth {
-	status = "okay";
+		port@2 {
+			status = "okay";
+			label = "lan2";
+		};
+
+		port@3 {
+			status = "okay";
+			label = "lan3";
+		};
 
-	mdio-bus {
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		switch@0 {
-			compatible = "mediatek,mt7530";
-			reg = <0>;
-			mediatek,mcm;
-			resets = <&ethsys MT2701_ETHSYS_MCM_RST>;
-			reset-names = "mcm";
-			core-supply = <&mt6323_vpa_reg>;
-			io-supply = <&mt6323_vemc3v3_reg>;
-
-			ports {
-				#address-cells = <1>;
-				#size-cells = <0>;
-
-				port@0 {
-					reg = <0>;
-					label = "lan0";
-				};
-
-				port@1 {
-					reg = <1>;
-					label = "lan1";
-				};
-
-				port@2 {
-					reg = <2>;
-					label = "lan2";
-				};
-
-				port@3 {
-					reg = <3>;
-					label = "lan3";
-				};
-
-				port@4 {
-					reg = <4>;
-					label = "wan";
-				};
-
-				port@6 {
-					reg = <6>;
-					label = "cpu";
-					ethernet = <&gmac0>;
-					phy-mode = "trgmii";
-
-					fixed-link {
-						speed = <1000>;
-						full-duplex;
-					};
-				};
-			};
+		port@4 {
+			status = "okay";
+			label = "wan";
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/mt7623a-rfb-nand.dts b/arch/arm/boot/dts/mt7623a-rfb-nand.dts
index fac3ca0322c8..afd177b3b516 100644
--- a/arch/arm/boot/dts/mt7623a-rfb-nand.dts
+++ b/arch/arm/boot/dts/mt7623a-rfb-nand.dts
@@ -116,74 +116,31 @@ &crypto {
 	status = "okay";
 };
 
-&gmac0 {
-	status = "okay";
-	phy-mode = "trgmii";
+&switch0 {
+	ports {
+		port@0 {
+			status = "okay";
+			label = "lan0";
+		};
 
-	fixed-link {
-		speed = <1000>;
-		full-duplex;
-		pause;
-	};
-};
+		port@1 {
+			status = "okay";
+			label = "lan1";
+		};
 
-&eth {
-	status = "okay";
+		port@2 {
+			status = "okay";
+			label = "lan2";
+		};
 
-	mdio-bus {
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		switch@0 {
-			compatible = "mediatek,mt7530";
-			reg = <0>;
-			mediatek,mcm;
-			resets = <&ethsys MT2701_ETHSYS_MCM_RST>;
-			reset-names = "mcm";
-			core-supply = <&mt6323_vpa_reg>;
-			io-supply = <&mt6323_vemc3v3_reg>;
-
-			ports {
-				#address-cells = <1>;
-				#size-cells = <0>;
-
-				port@0 {
-					reg = <0>;
-					label = "lan0";
-				};
-
-				port@1 {
-					reg = <1>;
-					label = "lan1";
-				};
-
-				port@2 {
-					reg = <2>;
-					label = "lan2";
-				};
-
-				port@3 {
-					reg = <3>;
-					label = "lan3";
-				};
-
-				port@4 {
-					reg = <4>;
-					label = "wan";
-				};
-
-				port@6 {
-					reg = <6>;
-					label = "cpu";
-					ethernet = <&gmac0>;
-					phy-mode = "trgmii";
-
-					fixed-link {
-						speed = <1000>;
-						full-duplex;
-					};
-				};
-			};
+		port@3 {
+			status = "okay";
+			label = "lan3";
+		};
+
+		port@4 {
+			status = "okay";
+			label = "wan";
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/mt7623a.dtsi b/arch/arm/boot/dts/mt7623a.dtsi
index d304b62d24b5..fbb5731a3a53 100644
--- a/arch/arm/boot/dts/mt7623a.dtsi
+++ b/arch/arm/boot/dts/mt7623a.dtsi
@@ -17,8 +17,82 @@ &crypto {
 	power-domains = <&scpsys MT7623A_POWER_DOMAIN_ETH>;
 };
 
+&gmac0 {
+	status = "okay";
+	phy-mode = "trgmii";
+
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+		pause;
+	};
+};
+
 &eth {
+	status = "okay";
 	power-domains = <&scpsys MT7623A_POWER_DOMAIN_ETH>;
+
+	mdio: mdio-bus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		switch0: switch@0 {
+			compatible = "mediatek,mt7530";
+			reg = <0>;
+			mediatek,mcm;
+			resets = <&ethsys MT2701_ETHSYS_MCM_RST>;
+			reset-names = "mcm";
+			core-supply = <&mt6323_vpa_reg>;
+			io-supply = <&mt6323_vemc3v3_reg>;
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					status = "disabled";
+					reg = <0>;
+					label = "swp0";
+				};
+
+				port@1 {
+					status = "disabled";
+					reg = <1>;
+					label = "swp1";
+				};
+
+				port@2 {
+					status = "disabled";
+					reg = <2>;
+					label = "swp2";
+				};
+
+				port@3 {
+					status = "disabled";
+					reg = <3>;
+					label = "swp3";
+				};
+
+				port@4 {
+					status = "disabled";
+					reg = <4>;
+					label = "swp4";
+				};
+
+				port@6 {
+					reg = <6>;
+					label = "cpu";
+					ethernet = <&gmac0>;
+					phy-mode = "trgmii";
+
+					fixed-link {
+						speed = <1000>;
+						full-duplex;
+					};
+				};
+			};
+		};
+	};
 };
 
 &nandc {
-- 
2.37.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 3/5] arm: dts: mt7623: change mt7530 switch address

[arinc9.unal]

From: Arınç ÜNAL <arinc.unal@arinc9.com>

In the case of muxing phy0 of the MT7530 switch, the switch and the phy
will have the same address on the mdio bus, 0. This causes the ethernet
driver to fail since devices on the mdio bus cannot share an address.

Any address can be used for the switch, therefore, change the switch
address to 0x1f.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
 arch/arm/boot/dts/mt7623a.dtsi                | 4 ++--
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 4 ++--
 arch/arm/boot/dts/mt7623n-rfb-emmc.dts        | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/mt7623a.dtsi b/arch/arm/boot/dts/mt7623a.dtsi
index fbb5731a3a53..dd522e508eb3 100644
--- a/arch/arm/boot/dts/mt7623a.dtsi
+++ b/arch/arm/boot/dts/mt7623a.dtsi
@@ -36,9 +36,9 @@ mdio: mdio-bus {
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		switch0: switch@0 {
+		switch0: switch@1f {
 			compatible = "mediatek,mt7530";
-			reg = <0>;
+			reg = <0x1f>;
 			mediatek,mcm;
 			resets = <&ethsys MT2701_ETHSYS_MCM_RST>;
 			reset-names = "mcm";
diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
index 1e03a3de654f..dc9b4f99eb8b 100644
--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
@@ -189,9 +189,9 @@ mdio-bus {
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		switch@0 {
+		switch@1f {
 			compatible = "mediatek,mt7530";
-			reg = <0>;
+			reg = <0x1f>;
 			reset-gpios = <&pio 33 0>;
 			core-supply = <&mt6323_vpa_reg>;
 			io-supply = <&mt6323_vemc3v3_reg>;
diff --git a/arch/arm/boot/dts/mt7623n-rfb-emmc.dts b/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
index 5e328c2a6a6e..6b0c3d1006ab 100644
--- a/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
+++ b/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
@@ -185,9 +185,9 @@ phy5: ethernet-phy@5 {
 			phy-mode = "rgmii-rxid";
 		};
 
-		switch@0 {
+		switch@1f {
 			compatible = "mediatek,mt7530";
-			reg = <0>;
+			reg = <0x1f>;
 			reset-gpios = <&pio 33 0>;
 			core-supply = <&mt6323_vpa_reg>;
 			io-supply = <&mt6323_vemc3v3_reg>;
-- 
2.37.2

[PATCH v2 3/5] arm: dts: mt7623: change mt7530 switch address

[arinc9.unal]

From: Arınç ÜNAL <arinc.unal@arinc9.com>

In the case of muxing phy0 of the MT7530 switch, the switch and the phy
will have the same address on the mdio bus, 0. This causes the ethernet
driver to fail since devices on the mdio bus cannot share an address.

Any address can be used for the switch, therefore, change the switch
address to 0x1f.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
 arch/arm/boot/dts/mt7623a.dtsi                | 4 ++--
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 4 ++--
 arch/arm/boot/dts/mt7623n-rfb-emmc.dts        | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/mt7623a.dtsi b/arch/arm/boot/dts/mt7623a.dtsi
index fbb5731a3a53..dd522e508eb3 100644
--- a/arch/arm/boot/dts/mt7623a.dtsi
+++ b/arch/arm/boot/dts/mt7623a.dtsi
@@ -36,9 +36,9 @@ mdio: mdio-bus {
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		switch0: switch@0 {
+		switch0: switch@1f {
 			compatible = "mediatek,mt7530";
-			reg = <0>;
+			reg = <0x1f>;
 			mediatek,mcm;
 			resets = <&ethsys MT2701_ETHSYS_MCM_RST>;
 			reset-names = "mcm";
diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
index 1e03a3de654f..dc9b4f99eb8b 100644
--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
@@ -189,9 +189,9 @@ mdio-bus {
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		switch@0 {
+		switch@1f {
 			compatible = "mediatek,mt7530";
-			reg = <0>;
+			reg = <0x1f>;
 			reset-gpios = <&pio 33 0>;
 			core-supply = <&mt6323_vpa_reg>;
 			io-supply = <&mt6323_vemc3v3_reg>;
diff --git a/arch/arm/boot/dts/mt7623n-rfb-emmc.dts b/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
index 5e328c2a6a6e..6b0c3d1006ab 100644
--- a/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
+++ b/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
@@ -185,9 +185,9 @@ phy5: ethernet-phy@5 {
 			phy-mode = "rgmii-rxid";
 		};
 
-		switch@0 {
+		switch@1f {
 			compatible = "mediatek,mt7530";
-			reg = <0>;
+			reg = <0x1f>;
 			reset-gpios = <&pio 33 0>;
 			core-supply = <&mt6323_vpa_reg>;
 			io-supply = <&mt6323_vemc3v3_reg>;
-- 
2.37.2

[PATCH v2 3/5] arm: dts: mt7623: change mt7530 switch address

[arinc9.unal]

From: Arınç ÜNAL <arinc.unal@arinc9.com>

In the case of muxing phy0 of the MT7530 switch, the switch and the phy
will have the same address on the mdio bus, 0. This causes the ethernet
driver to fail since devices on the mdio bus cannot share an address.

Any address can be used for the switch, therefore, change the switch
address to 0x1f.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
 arch/arm/boot/dts/mt7623a.dtsi                | 4 ++--
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 4 ++--
 arch/arm/boot/dts/mt7623n-rfb-emmc.dts        | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/mt7623a.dtsi b/arch/arm/boot/dts/mt7623a.dtsi
index fbb5731a3a53..dd522e508eb3 100644
--- a/arch/arm/boot/dts/mt7623a.dtsi
+++ b/arch/arm/boot/dts/mt7623a.dtsi
@@ -36,9 +36,9 @@ mdio: mdio-bus {
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		switch0: switch@0 {
+		switch0: switch@1f {
 			compatible = "mediatek,mt7530";
-			reg = <0>;
+			reg = <0x1f>;
 			mediatek,mcm;
 			resets = <&ethsys MT2701_ETHSYS_MCM_RST>;
 			reset-names = "mcm";
diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
index 1e03a3de654f..dc9b4f99eb8b 100644
--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
@@ -189,9 +189,9 @@ mdio-bus {
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		switch@0 {
+		switch@1f {
 			compatible = "mediatek,mt7530";
-			reg = <0>;
+			reg = <0x1f>;
 			reset-gpios = <&pio 33 0>;
 			core-supply = <&mt6323_vpa_reg>;
 			io-supply = <&mt6323_vemc3v3_reg>;
diff --git a/arch/arm/boot/dts/mt7623n-rfb-emmc.dts b/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
index 5e328c2a6a6e..6b0c3d1006ab 100644
--- a/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
+++ b/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
@@ -185,9 +185,9 @@ phy5: ethernet-phy@5 {
 			phy-mode = "rgmii-rxid";
 		};
 
-		switch@0 {
+		switch@1f {
 			compatible = "mediatek,mt7530";
-			reg = <0>;
+			reg = <0x1f>;
 			reset-gpios = <&pio 33 0>;
 			core-supply = <&mt6323_vpa_reg>;
 			io-supply = <&mt6323_vemc3v3_reg>;
-- 
2.37.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[arinc9.unal]

From: Arınç ÜNAL <arinc.unal@arinc9.com>

Mux the MT7530 switch's phy0 to gmac5 which is wired to the SoC's gmac1.
This achieves 2 Gbps total bandwidth to the CPU using the second RGMII.

With this, the interface name to access phy0 changes from wan to eth1.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
index dc9b4f99eb8b..64700253fd35 100644
--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
@@ -182,6 +182,12 @@ fixed-link {
 	};
 };
 
+&gmac1 {
+	status = "okay";
+	phy-mode = "rgmii";
+	phy-handle = <&ethphy0>;
+};
+
 &eth {
 	status = "okay";
 
@@ -189,6 +195,10 @@ mdio-bus {
 		#address-cells = <1>;
 		#size-cells = <0>;
 
+		ethphy0: ethernet-phy@0 {
+			reg = <0>;
+		};
+
 		switch@1f {
 			compatible = "mediatek,mt7530";
 			reg = <0x1f>;
@@ -200,11 +210,6 @@ ports {
 				#address-cells = <1>;
 				#size-cells = <0>;
 
-				port@0 {
-					reg = <0>;
-					label = "wan";
-				};
-
 				port@1 {
 					reg = <1>;
 					label = "lan0";
-- 
2.37.2

[PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[arinc9.unal]

From: Arınç ÜNAL <arinc.unal@arinc9.com>

Mux the MT7530 switch's phy0 to gmac5 which is wired to the SoC's gmac1.
This achieves 2 Gbps total bandwidth to the CPU using the second RGMII.

With this, the interface name to access phy0 changes from wan to eth1.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
index dc9b4f99eb8b..64700253fd35 100644
--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
@@ -182,6 +182,12 @@ fixed-link {
 	};
 };
 
+&gmac1 {
+	status = "okay";
+	phy-mode = "rgmii";
+	phy-handle = <&ethphy0>;
+};
+
 &eth {
 	status = "okay";
 
@@ -189,6 +195,10 @@ mdio-bus {
 		#address-cells = <1>;
 		#size-cells = <0>;
 
+		ethphy0: ethernet-phy@0 {
+			reg = <0>;
+		};
+
 		switch@1f {
 			compatible = "mediatek,mt7530";
 			reg = <0x1f>;
@@ -200,11 +210,6 @@ ports {
 				#address-cells = <1>;
 				#size-cells = <0>;
 
-				port@0 {
-					reg = <0>;
-					label = "wan";
-				};
-
 				port@1 {
 					reg = <1>;
 					label = "lan0";
-- 
2.37.2

[PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[arinc9.unal]

From: Arınç ÜNAL <arinc.unal@arinc9.com>

Mux the MT7530 switch's phy0 to gmac5 which is wired to the SoC's gmac1.
This achieves 2 Gbps total bandwidth to the CPU using the second RGMII.

With this, the interface name to access phy0 changes from wan to eth1.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
index dc9b4f99eb8b..64700253fd35 100644
--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
@@ -182,6 +182,12 @@ fixed-link {
 	};
 };
 
+&gmac1 {
+	status = "okay";
+	phy-mode = "rgmii";
+	phy-handle = <&ethphy0>;
+};
+
 &eth {
 	status = "okay";
 
@@ -189,6 +195,10 @@ mdio-bus {
 		#address-cells = <1>;
 		#size-cells = <0>;
 
+		ethphy0: ethernet-phy@0 {
+			reg = <0>;
+		};
+
 		switch@1f {
 			compatible = "mediatek,mt7530";
 			reg = <0x1f>;
@@ -200,11 +210,6 @@ ports {
 				#address-cells = <1>;
 				#size-cells = <0>;
 
-				port@0 {
-					reg = <0>;
-					label = "wan";
-				};
-
 				port@1 {
 					reg = <1>;
 					label = "lan0";
-- 
2.37.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 5/5] arm: dts: mt7623: enable flow control on port@6

[arinc9.unal]

From: Arınç ÜNAL <arinc.unal@arinc9.com>

Flow control needs to be enabled on both sides to work.
It is already enabled on gmac0, enable it on port@6 too.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
 arch/arm/boot/dts/mt7623a.dtsi         | 1 +
 arch/arm/boot/dts/mt7623n-rfb-emmc.dts | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/mt7623a.dtsi b/arch/arm/boot/dts/mt7623a.dtsi
index dd522e508eb3..2a50b5c0c933 100644
--- a/arch/arm/boot/dts/mt7623a.dtsi
+++ b/arch/arm/boot/dts/mt7623a.dtsi
@@ -88,6 +88,7 @@ port@6 {
 					fixed-link {
 						speed = <1000>;
 						full-duplex;
+						pause;
 					};
 				};
 			};
diff --git a/arch/arm/boot/dts/mt7623n-rfb-emmc.dts b/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
index 6b0c3d1006ab..34994f3f5a4b 100644
--- a/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
+++ b/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
@@ -230,6 +230,7 @@ port@6 {
 					fixed-link {
 						speed = <1000>;
 						full-duplex;
+						pause;
 					};
 				};
 			};
-- 
2.37.2

[PATCH v2 5/5] arm: dts: mt7623: enable flow control on port@6

[arinc9.unal]

From: Arınç ÜNAL <arinc.unal@arinc9.com>

Flow control needs to be enabled on both sides to work.
It is already enabled on gmac0, enable it on port@6 too.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
 arch/arm/boot/dts/mt7623a.dtsi         | 1 +
 arch/arm/boot/dts/mt7623n-rfb-emmc.dts | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/mt7623a.dtsi b/arch/arm/boot/dts/mt7623a.dtsi
index dd522e508eb3..2a50b5c0c933 100644
--- a/arch/arm/boot/dts/mt7623a.dtsi
+++ b/arch/arm/boot/dts/mt7623a.dtsi
@@ -88,6 +88,7 @@ port@6 {
 					fixed-link {
 						speed = <1000>;
 						full-duplex;
+						pause;
 					};
 				};
 			};
diff --git a/arch/arm/boot/dts/mt7623n-rfb-emmc.dts b/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
index 6b0c3d1006ab..34994f3f5a4b 100644
--- a/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
+++ b/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
@@ -230,6 +230,7 @@ port@6 {
 					fixed-link {
 						speed = <1000>;
 						full-duplex;
+						pause;
 					};
 				};
 			};
-- 
2.37.2

[PATCH v2 5/5] arm: dts: mt7623: enable flow control on port@6

[arinc9.unal]

From: Arınç ÜNAL <arinc.unal@arinc9.com>

Flow control needs to be enabled on both sides to work.
It is already enabled on gmac0, enable it on port@6 too.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
 arch/arm/boot/dts/mt7623a.dtsi         | 1 +
 arch/arm/boot/dts/mt7623n-rfb-emmc.dts | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/mt7623a.dtsi b/arch/arm/boot/dts/mt7623a.dtsi
index dd522e508eb3..2a50b5c0c933 100644
--- a/arch/arm/boot/dts/mt7623a.dtsi
+++ b/arch/arm/boot/dts/mt7623a.dtsi
@@ -88,6 +88,7 @@ port@6 {
 					fixed-link {
 						speed = <1000>;
 						full-duplex;
+						pause;
 					};
 				};
 			};
diff --git a/arch/arm/boot/dts/mt7623n-rfb-emmc.dts b/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
index 6b0c3d1006ab..34994f3f5a4b 100644
--- a/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
+++ b/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
@@ -230,6 +230,7 @@ port@6 {
 					fixed-link {
 						speed = <1000>;
 						full-duplex;
+						pause;
 					};
 				};
 			};
-- 
2.37.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[Frank Wunderlich]

Am 1. Februar 2023 19:56:55 MEZ schrieb arinc9.unal@gmail.com:
>From: Arınç ÜNAL <arinc.unal@arinc9.com>
>
>Mux the MT7530 switch's phy0 to gmac5 which is wired to the SoC's gmac1.
>This achieves 2 Gbps total bandwidth to the CPU using the second RGMII.
>
>With this, the interface name to access phy0 changes from wan to eth1.
>
>Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
>---
> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
>diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
>index dc9b4f99eb8b..64700253fd35 100644
>--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
>+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
>@@ -182,6 +182,12 @@ fixed-link {
> 	};
> };
> 
>+&gmac1 {
>+	status = "okay";
>+	phy-mode = "rgmii";
>+	phy-handle = <&ethphy0>;
>+};
>+
> &eth {
> 	status = "okay";
> 
>@@ -189,6 +195,10 @@ mdio-bus {
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 
>+		ethphy0: ethernet-phy@0 {
>+			reg = <0>;
>+		};
>+
> 		switch@1f {
> 			compatible = "mediatek,mt7530";
> 			reg = <0x1f>;
>@@ -200,11 +210,6 @@ ports {
> 				#address-cells = <1>;
> 				#size-cells = <0>;
> 
>-				port@0 {
>-					reg = <0>;
>-					label = "wan";
>-				};
>-
> 				port@1 {
> 					reg = <1>;
> 					label = "lan0";

Hi

I still see Problem with "renaming" the wan from users PoV. I got another way of using second gmac for wan some time ago using vlan-aware bridge (have not tested with recent kernel versions).

Maybe this works for you too? If yes imho it will be a better way.

https://github.com/frank-w/BPI-Router-Linux/commit/c92b648bac996b34dc75a4fff15d7fb429bfe74b

Have same for r64/mt7622 in my tree...

It should use eth1 for wan-traffic too but is full userspace configuration without breaking userspace for users not wanting it.
regards Frank

Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[Frank Wunderlich]

Am 1. Februar 2023 19:56:55 MEZ schrieb arinc9.unal@gmail.com:
>From: Arınç ÜNAL <arinc.unal@arinc9.com>
>
>Mux the MT7530 switch's phy0 to gmac5 which is wired to the SoC's gmac1.
>This achieves 2 Gbps total bandwidth to the CPU using the second RGMII.
>
>With this, the interface name to access phy0 changes from wan to eth1.
>
>Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
>---
> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
>diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
>index dc9b4f99eb8b..64700253fd35 100644
>--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
>+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
>@@ -182,6 +182,12 @@ fixed-link {
> 	};
> };
> 
>+&gmac1 {
>+	status = "okay";
>+	phy-mode = "rgmii";
>+	phy-handle = <&ethphy0>;
>+};
>+
> &eth {
> 	status = "okay";
> 
>@@ -189,6 +195,10 @@ mdio-bus {
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 
>+		ethphy0: ethernet-phy@0 {
>+			reg = <0>;
>+		};
>+
> 		switch@1f {
> 			compatible = "mediatek,mt7530";
> 			reg = <0x1f>;
>@@ -200,11 +210,6 @@ ports {
> 				#address-cells = <1>;
> 				#size-cells = <0>;
> 
>-				port@0 {
>-					reg = <0>;
>-					label = "wan";
>-				};
>-
> 				port@1 {
> 					reg = <1>;
> 					label = "lan0";

Hi

I still see Problem with "renaming" the wan from users PoV. I got another way of using second gmac for wan some time ago using vlan-aware bridge (have not tested with recent kernel versions).

Maybe this works for you too? If yes imho it will be a better way.

https://github.com/frank-w/BPI-Router-Linux/commit/c92b648bac996b34dc75a4fff15d7fb429bfe74b

Have same for r64/mt7622 in my tree...

It should use eth1 for wan-traffic too but is full userspace configuration without breaking userspace for users not wanting it.
regards Frank

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[Arınç ÜNAL]

On 3.02.2023 18:36, Frank Wunderlich wrote:
> Am 1. Februar 2023 19:56:55 MEZ schrieb arinc9.unal@gmail.com:
>> From: Arınç ÜNAL <arinc.unal@arinc9.com>
>>
>> Mux the MT7530 switch's phy0 to gmac5 which is wired to the SoC's gmac1.
>> This achieves 2 Gbps total bandwidth to the CPU using the second RGMII.
>>
>> With this, the interface name to access phy0 changes from wan to eth1.
>>
>> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
>> ---
>> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 15 ++++++++++-----
>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
>> index dc9b4f99eb8b..64700253fd35 100644
>> --- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
>> +++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
>> @@ -182,6 +182,12 @@ fixed-link {
>> 	};
>> };
>>
>> +&gmac1 {
>> +	status = "okay";
>> +	phy-mode = "rgmii";
>> +	phy-handle = <&ethphy0>;
>> +};
>> +
>> &eth {
>> 	status = "okay";
>>
>> @@ -189,6 +195,10 @@ mdio-bus {
>> 		#address-cells = <1>;
>> 		#size-cells = <0>;
>>
>> +		ethphy0: ethernet-phy@0 {
>> +			reg = <0>;
>> +		};
>> +
>> 		switch@1f {
>> 			compatible = "mediatek,mt7530";
>> 			reg = <0x1f>;
>> @@ -200,11 +210,6 @@ ports {
>> 				#address-cells = <1>;
>> 				#size-cells = <0>;
>>
>> -				port@0 {
>> -					reg = <0>;
>> -					label = "wan";
>> -				};
>> -
>> 				port@1 {
>> 					reg = <1>;
>> 					label = "lan0";
> 
> Hi
> 
> I still see Problem with "renaming" the wan from users PoV. I got another way of using second gmac for wan some time ago using vlan-aware bridge (have not tested with recent kernel versions).
> 
> Maybe this works for you too? If yes imho it will be a better way.
> 
> https://github.com/frank-w/BPI-Router-Linux/commit/c92b648bac996b34dc75a4fff15d7fb429bfe74b

Frank, the comment section of that page is full of my comments testing 
it out and chatting with you. I don't understand why you're wording it 
like it's new to me.

> 
> Have same for r64/mt7622 in my tree...
> 
> It should use eth1 for wan-traffic too but is full userspace configuration without breaking userspace for users not wanting it.

If your argument is that connecting the wan port to the second mac 
should stay off mainline and to be left to the individual to do so, to 
not break the existing userspace configuration, this hack will need much 
more complex changes to the userspace configuration compared to this patch.

On top of this, you still need to change the devicetree to enable gmac1. 
And it will cause issues due to the nature of this method. Frames with 
the same MAC address will appear on different interfaces which will 
flood the kernel log, if eth1 were to be put in a bridge with other 
interfaces.

To summarise:
					This patch	Your method
Changes to the devicetree		Yes	(-)	Yes	(-)
Changes to the userspace configuration	Yes	(-)	Yes	(-)
Changes required in userspace		Simple	(+)	Complex	(-)
Does it work properly?			Yes	(+)	No	(-)

Using this patch would be the proper way to connect the wan port to the 
second mac.

I can also argue that I see no good reason to not want this, therefore 
this should be the default way. The UTP port for the wan port is 
seperated from the other 4 ports which already supports that this 
should've been there when the DT of this device was added in the first 
place.

If someone were to not want this, they could change the devicetree to 
fit their own purpose.

I did this on GnuBee GB-PC1 and it was easily addressed on gnubee-tools, 
a tool for building a firmware image for the said device.

https://github.com/neilbrown/gnubee-tools/commit/e1cdab9fd5f03ec4582176ab6eac9157df2a6f21

To conclude, in my opinion, gaining 2 Gbps total bandwidth to the CPU at 
the expense of a tiny change in userspace configuration is absolutely 
worth it. You clearly don't think that way and that's fine. It's up to 
the maintainer, Matthias, to decide. Matthias can take the remaining 
patches if they please.

Arınç

Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[Arınç ÜNAL]

On 3.02.2023 18:36, Frank Wunderlich wrote:
> Am 1. Februar 2023 19:56:55 MEZ schrieb arinc9.unal@gmail.com:
>> From: Arınç ÜNAL <arinc.unal@arinc9.com>
>>
>> Mux the MT7530 switch's phy0 to gmac5 which is wired to the SoC's gmac1.
>> This achieves 2 Gbps total bandwidth to the CPU using the second RGMII.
>>
>> With this, the interface name to access phy0 changes from wan to eth1.
>>
>> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
>> ---
>> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 15 ++++++++++-----
>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
>> index dc9b4f99eb8b..64700253fd35 100644
>> --- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
>> +++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
>> @@ -182,6 +182,12 @@ fixed-link {
>> 	};
>> };
>>
>> +&gmac1 {
>> +	status = "okay";
>> +	phy-mode = "rgmii";
>> +	phy-handle = <&ethphy0>;
>> +};
>> +
>> &eth {
>> 	status = "okay";
>>
>> @@ -189,6 +195,10 @@ mdio-bus {
>> 		#address-cells = <1>;
>> 		#size-cells = <0>;
>>
>> +		ethphy0: ethernet-phy@0 {
>> +			reg = <0>;
>> +		};
>> +
>> 		switch@1f {
>> 			compatible = "mediatek,mt7530";
>> 			reg = <0x1f>;
>> @@ -200,11 +210,6 @@ ports {
>> 				#address-cells = <1>;
>> 				#size-cells = <0>;
>>
>> -				port@0 {
>> -					reg = <0>;
>> -					label = "wan";
>> -				};
>> -
>> 				port@1 {
>> 					reg = <1>;
>> 					label = "lan0";
> 
> Hi
> 
> I still see Problem with "renaming" the wan from users PoV. I got another way of using second gmac for wan some time ago using vlan-aware bridge (have not tested with recent kernel versions).
> 
> Maybe this works for you too? If yes imho it will be a better way.
> 
> https://github.com/frank-w/BPI-Router-Linux/commit/c92b648bac996b34dc75a4fff15d7fb429bfe74b

Frank, the comment section of that page is full of my comments testing 
it out and chatting with you. I don't understand why you're wording it 
like it's new to me.

> 
> Have same for r64/mt7622 in my tree...
> 
> It should use eth1 for wan-traffic too but is full userspace configuration without breaking userspace for users not wanting it.

If your argument is that connecting the wan port to the second mac 
should stay off mainline and to be left to the individual to do so, to 
not break the existing userspace configuration, this hack will need much 
more complex changes to the userspace configuration compared to this patch.

On top of this, you still need to change the devicetree to enable gmac1. 
And it will cause issues due to the nature of this method. Frames with 
the same MAC address will appear on different interfaces which will 
flood the kernel log, if eth1 were to be put in a bridge with other 
interfaces.

To summarise:
					This patch	Your method
Changes to the devicetree		Yes	(-)	Yes	(-)
Changes to the userspace configuration	Yes	(-)	Yes	(-)
Changes required in userspace		Simple	(+)	Complex	(-)
Does it work properly?			Yes	(+)	No	(-)

Using this patch would be the proper way to connect the wan port to the 
second mac.

I can also argue that I see no good reason to not want this, therefore 
this should be the default way. The UTP port for the wan port is 
seperated from the other 4 ports which already supports that this 
should've been there when the DT of this device was added in the first 
place.

If someone were to not want this, they could change the devicetree to 
fit their own purpose.

I did this on GnuBee GB-PC1 and it was easily addressed on gnubee-tools, 
a tool for building a firmware image for the said device.

https://github.com/neilbrown/gnubee-tools/commit/e1cdab9fd5f03ec4582176ab6eac9157df2a6f21

To conclude, in my opinion, gaining 2 Gbps total bandwidth to the CPU at 
the expense of a tiny change in userspace configuration is absolutely 
worth it. You clearly don't think that way and that's fine. It's up to 
the maintainer, Matthias, to decide. Matthias can take the remaining 
patches if they please.

Arınç

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[Frank Wunderlich]

Am 3. Februar 2023 19:20:48 MEZ schrieb "Arınç ÜNAL" <arinc.unal@arinc9.com>:
>On 3.02.2023 18:36, Frank Wunderlich wrote:
>> Am 1. Februar 2023 19:56:55 MEZ schrieb arinc9.unal@gmail.com:
>>> From: Arınç ÜNAL <arinc.unal@arinc9.com>
>>> 
>>> Mux the MT7530 switch's phy0 to gmac5 which is wired to the SoC's gmac1.
>>> This achieves 2 Gbps total bandwidth to the CPU using the second RGMII.
>>> 
>>> With this, the interface name to access phy0 changes from wan to eth1.
>>> 
>>> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
>>> ---
>>> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 15 ++++++++++-----
>>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>> 
>>> diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
>>> index dc9b4f99eb8b..64700253fd35 100644
>>> --- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
>>> +++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
>>> @@ -182,6 +182,12 @@ fixed-link {
>>> 	};
>>> };
>>> 
>>> +&gmac1 {
>>> +	status = "okay";
>>> +	phy-mode = "rgmii";
>>> +	phy-handle = <&ethphy0>;
>>> +};
>>> +
>>> &eth {
>>> 	status = "okay";
>>> 
>>> @@ -189,6 +195,10 @@ mdio-bus {
>>> 		#address-cells = <1>;
>>> 		#size-cells = <0>;
>>> 
>>> +		ethphy0: ethernet-phy@0 {
>>> +			reg = <0>;
>>> +		};
>>> +
>>> 		switch@1f {
>>> 			compatible = "mediatek,mt7530";
>>> 			reg = <0x1f>;
>>> @@ -200,11 +210,6 @@ ports {
>>> 				#address-cells = <1>;
>>> 				#size-cells = <0>;
>>> 
>>> -				port@0 {
>>> -					reg = <0>;
>>> -					label = "wan";
>>> -				};
>>> -
>>> 				port@1 {
>>> 					reg = <1>;
>>> 					label = "lan0";
>> 
>> Hi
>> 
>> I still see Problem with "renaming" the wan from users PoV. I got another way of using second gmac for wan some time ago using vlan-aware bridge (have not tested with recent kernel versions).
>> 
>> Maybe this works for you too? If yes imho it will be a better way.
>> 
>> https://github.com/frank-w/BPI-Router-Linux/commit/c92b648bac996b34dc75a4fff15d7fb429bfe74b
>
>Frank, the comment section of that page is full of my comments testing it out and chatting with you. I don't understand why you're wording it like it's new to me.

Not new,but you have not told me the issues you have with this way.

>> 
>> Have same for r64/mt7622 in my tree...
>> 
>> It should use eth1 for wan-traffic too but is full userspace configuration without breaking userspace for users not wanting it.
>
>If your argument is that connecting the wan port to the second mac should stay off mainline and to be left to the individual to do so, to not break the existing userspace configuration, this hack will need much more complex changes to the userspace configuration compared to this patch.

Yes,userspace config is more complex,but till now i thought both ways had same result except that user can decide if he wants interface name changed. I try to find some time to test your approach this weekend.

>On top of this, you still need to change the devicetree to enable gmac1. And it will cause issues due to the nature of this method. Frames with the same MAC address will appear on different interfaces which will flood the kernel log, if eth1 were to be put in a bridge with other interfaces.

This information is new to me. Had only made some basic tests with the way in my repo and did not noticed this flooding.

>To summarise:
>					This patch	Your method
>Changes to the devicetree		Yes	(-)	Yes	(-)
>Changes to the userspace configuration	Yes	(-)	Yes	(-)
>Changes required in userspace		Simple	(+)	Complex	(-)
>Does it work properly?			Yes	(+)	No	(-)
>
>Using this patch would be the proper way to connect the wan port to the second mac.
>
>I can also argue that I see no good reason to not want this, therefore this should be the default way. The UTP port for the wan port is seperated from the other 4 ports which already supports that this should've been there when the DT of this device was added in the first place.

There was a hope that dsa will support multiple cpu ports some time and there are several attempts to get it into mainline.

>If someone were to not want this, they could change the devicetree to fit their own purpose.
>
>To conclude, in my opinion, gaining 2 Gbps total bandwidth to the CPU at the expense of a tiny change in userspace configuration is absolutely worth it. You clearly don't think that way and that's fine. It's up to the maintainer, Matthias, to decide. Matthias can take the remaining patches if they please.

I appreciate you efforts to getting better performance here. Idk how many users will benefit from it...i have only 25mbit/s connection and can configure my dt/userspace...only thought about users not able to do so and may confused by this and do not "need" the change.

>Arınç


regards Frank

Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[Frank Wunderlich]

Am 3. Februar 2023 19:20:48 MEZ schrieb "Arınç ÜNAL" <arinc.unal@arinc9.com>:
>On 3.02.2023 18:36, Frank Wunderlich wrote:
>> Am 1. Februar 2023 19:56:55 MEZ schrieb arinc9.unal@gmail.com:
>>> From: Arınç ÜNAL <arinc.unal@arinc9.com>
>>> 
>>> Mux the MT7530 switch's phy0 to gmac5 which is wired to the SoC's gmac1.
>>> This achieves 2 Gbps total bandwidth to the CPU using the second RGMII.
>>> 
>>> With this, the interface name to access phy0 changes from wan to eth1.
>>> 
>>> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
>>> ---
>>> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 15 ++++++++++-----
>>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>> 
>>> diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
>>> index dc9b4f99eb8b..64700253fd35 100644
>>> --- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
>>> +++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
>>> @@ -182,6 +182,12 @@ fixed-link {
>>> 	};
>>> };
>>> 
>>> +&gmac1 {
>>> +	status = "okay";
>>> +	phy-mode = "rgmii";
>>> +	phy-handle = <&ethphy0>;
>>> +};
>>> +
>>> &eth {
>>> 	status = "okay";
>>> 
>>> @@ -189,6 +195,10 @@ mdio-bus {
>>> 		#address-cells = <1>;
>>> 		#size-cells = <0>;
>>> 
>>> +		ethphy0: ethernet-phy@0 {
>>> +			reg = <0>;
>>> +		};
>>> +
>>> 		switch@1f {
>>> 			compatible = "mediatek,mt7530";
>>> 			reg = <0x1f>;
>>> @@ -200,11 +210,6 @@ ports {
>>> 				#address-cells = <1>;
>>> 				#size-cells = <0>;
>>> 
>>> -				port@0 {
>>> -					reg = <0>;
>>> -					label = "wan";
>>> -				};
>>> -
>>> 				port@1 {
>>> 					reg = <1>;
>>> 					label = "lan0";
>> 
>> Hi
>> 
>> I still see Problem with "renaming" the wan from users PoV. I got another way of using second gmac for wan some time ago using vlan-aware bridge (have not tested with recent kernel versions).
>> 
>> Maybe this works for you too? If yes imho it will be a better way.
>> 
>> https://github.com/frank-w/BPI-Router-Linux/commit/c92b648bac996b34dc75a4fff15d7fb429bfe74b
>
>Frank, the comment section of that page is full of my comments testing it out and chatting with you. I don't understand why you're wording it like it's new to me.

Not new,but you have not told me the issues you have with this way.

>> 
>> Have same for r64/mt7622 in my tree...
>> 
>> It should use eth1 for wan-traffic too but is full userspace configuration without breaking userspace for users not wanting it.
>
>If your argument is that connecting the wan port to the second mac should stay off mainline and to be left to the individual to do so, to not break the existing userspace configuration, this hack will need much more complex changes to the userspace configuration compared to this patch.

Yes,userspace config is more complex,but till now i thought both ways had same result except that user can decide if he wants interface name changed. I try to find some time to test your approach this weekend.

>On top of this, you still need to change the devicetree to enable gmac1. And it will cause issues due to the nature of this method. Frames with the same MAC address will appear on different interfaces which will flood the kernel log, if eth1 were to be put in a bridge with other interfaces.

This information is new to me. Had only made some basic tests with the way in my repo and did not noticed this flooding.

>To summarise:
>					This patch	Your method
>Changes to the devicetree		Yes	(-)	Yes	(-)
>Changes to the userspace configuration	Yes	(-)	Yes	(-)
>Changes required in userspace		Simple	(+)	Complex	(-)
>Does it work properly?			Yes	(+)	No	(-)
>
>Using this patch would be the proper way to connect the wan port to the second mac.
>
>I can also argue that I see no good reason to not want this, therefore this should be the default way. The UTP port for the wan port is seperated from the other 4 ports which already supports that this should've been there when the DT of this device was added in the first place.

There was a hope that dsa will support multiple cpu ports some time and there are several attempts to get it into mainline.

>If someone were to not want this, they could change the devicetree to fit their own purpose.
>
>To conclude, in my opinion, gaining 2 Gbps total bandwidth to the CPU at the expense of a tiny change in userspace configuration is absolutely worth it. You clearly don't think that way and that's fine. It's up to the maintainer, Matthias, to decide. Matthias can take the remaining patches if they please.

I appreciate you efforts to getting better performance here. Idk how many users will benefit from it...i have only 25mbit/s connection and can configure my dt/userspace...only thought about users not able to do so and may confused by this and do not "need" the change.

>Arınç


regards Frank

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Aw: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[Frank Wunderlich]

Hi aranc,

have tested this series, basicly it works, but i get only ~620 Mbits/sec (much more i will need on wan) in tx-mode of r2, rx-mode (iperf3 -c IP -R on r2) gets full 939 Mbits/sec. Both no retransmitts.

tried with my laptop which gets 940Mbit/sec in tx mode too...other end is a R2 with 5.15 connected to lan0 (and eth1+aux enabled, dmesg clean so far...for the "kernel log flooded"-comment).

maybe gmac1 needs to be tweaked a bit (clock-settings)?

can you confirm this with your board?

regards Frank

Aw: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[Frank Wunderlich]

Hi aranc,

have tested this series, basicly it works, but i get only ~620 Mbits/sec (much more i will need on wan) in tx-mode of r2, rx-mode (iperf3 -c IP -R on r2) gets full 939 Mbits/sec. Both no retransmitts.

tried with my laptop which gets 940Mbit/sec in tx mode too...other end is a R2 with 5.15 connected to lan0 (and eth1+aux enabled, dmesg clean so far...for the "kernel log flooded"-comment).

maybe gmac1 needs to be tweaked a bit (clock-settings)?

can you confirm this with your board?

regards Frank

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Aw: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[Frank Wunderlich]

> Gesendet: Samstag, 04. Februar 2023 um 11:27 Uhr
> Von: "Frank Wunderlich" <frank-w@public-files.de>
> An: "Arınç ÜNAL" <arinc.unal@arinc9.com>
> Cc: arinc9.unal@gmail.com, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Matthias Brugger" <matthias.bgg@gmail.com>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, erkin.bozoglu@xeront.com, "Sean Wang" <sean.wang@mediatek.com>, "DENG Qingfang" <dqfext@gmail.com>
> Betreff: Aw: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2
>
> Hi aranc,
> 
> have tested this series, basicly it works, but i get only ~620 Mbits/sec (much more i will need on wan) in tx-mode of r2, rx-mode (iperf3 -c IP -R on r2) gets full 939 Mbits/sec. Both no retransmitts.
> 
> tried with my laptop which gets 940Mbit/sec in tx mode too...other end is a R2 with 5.15 connected to lan0 (and eth1+aux enabled, dmesg clean so far...for the "kernel log flooded"-comment).
> 
> maybe gmac1 needs to be tweaked a bit (clock-settings)?
> 
> can you confirm this with your board?

tested the vlan_aware way with 5.15.80 and got better result

ip link add br0 type bridge vlan_filtering 1
ip l set aux master br0
ip l set wan master br0
bridge vlan add vid 99 dev wan
bridge vlan add vid 99 dev aux
bridge vlan
ip l s eth1 up
ip l s wan up
ip a a 192.168.0.11/24 dev eth1
ip l s br0 up
ip l s aux up

i see traffic on eth1 increasing and iperf3 shows in both directions ~940Mbit/s, no strange mesages in dmesg while testing...where do you see these?

tested vlan-way with 6.2 and felix' Patches to more comparable with your test...and got same result (~625Mbit/s in tx and 940Mbit/s in rx-mode=-R on r2)...so it seems anything between 5.15 and 6.2 reduced gmac1 tx bandwidth.

to summarize:

i get same result with your patches and my old vlan_bridge way with same codebase...how do i see your problem with the vlan-bridge-way? Do you test with bpi-r2 or only any other board and change r2 to have same DT?

regards Frank

Aw: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[Frank Wunderlich]

> Gesendet: Samstag, 04. Februar 2023 um 11:27 Uhr
> Von: "Frank Wunderlich" <frank-w@public-files.de>
> An: "Arınç ÜNAL" <arinc.unal@arinc9.com>
> Cc: arinc9.unal@gmail.com, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Matthias Brugger" <matthias.bgg@gmail.com>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, erkin.bozoglu@xeront.com, "Sean Wang" <sean.wang@mediatek.com>, "DENG Qingfang" <dqfext@gmail.com>
> Betreff: Aw: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2
>
> Hi aranc,
> 
> have tested this series, basicly it works, but i get only ~620 Mbits/sec (much more i will need on wan) in tx-mode of r2, rx-mode (iperf3 -c IP -R on r2) gets full 939 Mbits/sec. Both no retransmitts.
> 
> tried with my laptop which gets 940Mbit/sec in tx mode too...other end is a R2 with 5.15 connected to lan0 (and eth1+aux enabled, dmesg clean so far...for the "kernel log flooded"-comment).
> 
> maybe gmac1 needs to be tweaked a bit (clock-settings)?
> 
> can you confirm this with your board?

tested the vlan_aware way with 5.15.80 and got better result

ip link add br0 type bridge vlan_filtering 1
ip l set aux master br0
ip l set wan master br0
bridge vlan add vid 99 dev wan
bridge vlan add vid 99 dev aux
bridge vlan
ip l s eth1 up
ip l s wan up
ip a a 192.168.0.11/24 dev eth1
ip l s br0 up
ip l s aux up

i see traffic on eth1 increasing and iperf3 shows in both directions ~940Mbit/s, no strange mesages in dmesg while testing...where do you see these?

tested vlan-way with 6.2 and felix' Patches to more comparable with your test...and got same result (~625Mbit/s in tx and 940Mbit/s in rx-mode=-R on r2)...so it seems anything between 5.15 and 6.2 reduced gmac1 tx bandwidth.

to summarize:

i get same result with your patches and my old vlan_bridge way with same codebase...how do i see your problem with the vlan-bridge-way? Do you test with bpi-r2 or only any other board and change r2 to have same DT?

regards Frank

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Aw: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[Arınç ÜNAL]

On 4.02.2023 14:43, Frank Wunderlich wrote:
>> Gesendet: Samstag, 04. Februar 2023 um 11:27 Uhr
>> Von: "Frank Wunderlich" <frank-w@public-files.de>
>> An: "Arınç ÜNAL" <arinc.unal@arinc9.com>
>> Cc: arinc9.unal@gmail.com, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Matthias Brugger" <matthias.bgg@gmail.com>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, erkin.bozoglu@xeront.com, "Sean Wang" <sean.wang@mediatek.com>, "DENG Qingfang" <dqfext@gmail.com>
>> Betreff: Aw: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2
>>
>> Hi aranc,
>>
>> have tested this series, basicly it works, but i get only ~620 Mbits/sec (much more i will need on wan) in tx-mode of r2, rx-mode (iperf3 -c IP -R on r2) gets full 939 Mbits/sec. Both no retransmitts.
>>
>> tried with my laptop which gets 940Mbit/sec in tx mode too...other end is a R2 with 5.15 connected to lan0 (and eth1+aux enabled, dmesg clean so far...for the "kernel log flooded"-comment).
>>
>> maybe gmac1 needs to be tweaked a bit (clock-settings)?
>>
>> can you confirm this with your board?
> 
> tested the vlan_aware way with 5.15.80 and got better result
> 
> ip link add br0 type bridge vlan_filtering 1
> ip l set aux master br0
> ip l set wan master br0
> bridge vlan add vid 99 dev wan
> bridge vlan add vid 99 dev aux
> bridge vlan
> ip l s eth1 up
> ip l s wan up
> ip a a 192.168.0.11/24 dev eth1
> ip l s br0 up
> ip l s aux up
> 
> i see traffic on eth1 increasing and iperf3 shows in both directions ~940Mbit/s, no strange mesages in dmesg while testing...where do you see these?

You didn't put eth1 on a bridge. I suggest you read my mails with higher 
attention so both of our time is spent efficiently.

> 
> tested vlan-way with 6.2 and felix' Patches to more comparable with your test...and got same result (~625Mbit/s in tx and 940Mbit/s in rx-mode=-R on r2)...so it seems anything between 5.15 and 6.2 reduced gmac1 tx bandwidth.

I don't see an incentive to investigate unless the issue is confirmed on 
a daily netdev/net-next.git main tree.

> 
> to summarize:
> 
> i get same result with your patches and my old vlan_bridge way with same codebase...how do i see your problem with the vlan-bridge-way? Do you test with bpi-r2 or only any other board and change r2 to have same DT?

I tested this only on a Bananapi BPI-R2 using the devicetree with this 
series applied on a few days old netdev/net-next.git main tree.

Arınç

Re: Aw: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[Arınç ÜNAL]

On 4.02.2023 14:43, Frank Wunderlich wrote:
>> Gesendet: Samstag, 04. Februar 2023 um 11:27 Uhr
>> Von: "Frank Wunderlich" <frank-w@public-files.de>
>> An: "Arınç ÜNAL" <arinc.unal@arinc9.com>
>> Cc: arinc9.unal@gmail.com, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Matthias Brugger" <matthias.bgg@gmail.com>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, erkin.bozoglu@xeront.com, "Sean Wang" <sean.wang@mediatek.com>, "DENG Qingfang" <dqfext@gmail.com>
>> Betreff: Aw: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2
>>
>> Hi aranc,
>>
>> have tested this series, basicly it works, but i get only ~620 Mbits/sec (much more i will need on wan) in tx-mode of r2, rx-mode (iperf3 -c IP -R on r2) gets full 939 Mbits/sec. Both no retransmitts.
>>
>> tried with my laptop which gets 940Mbit/sec in tx mode too...other end is a R2 with 5.15 connected to lan0 (and eth1+aux enabled, dmesg clean so far...for the "kernel log flooded"-comment).
>>
>> maybe gmac1 needs to be tweaked a bit (clock-settings)?
>>
>> can you confirm this with your board?
> 
> tested the vlan_aware way with 5.15.80 and got better result
> 
> ip link add br0 type bridge vlan_filtering 1
> ip l set aux master br0
> ip l set wan master br0
> bridge vlan add vid 99 dev wan
> bridge vlan add vid 99 dev aux
> bridge vlan
> ip l s eth1 up
> ip l s wan up
> ip a a 192.168.0.11/24 dev eth1
> ip l s br0 up
> ip l s aux up
> 
> i see traffic on eth1 increasing and iperf3 shows in both directions ~940Mbit/s, no strange mesages in dmesg while testing...where do you see these?

You didn't put eth1 on a bridge. I suggest you read my mails with higher 
attention so both of our time is spent efficiently.

> 
> tested vlan-way with 6.2 and felix' Patches to more comparable with your test...and got same result (~625Mbit/s in tx and 940Mbit/s in rx-mode=-R on r2)...so it seems anything between 5.15 and 6.2 reduced gmac1 tx bandwidth.

I don't see an incentive to investigate unless the issue is confirmed on 
a daily netdev/net-next.git main tree.

> 
> to summarize:
> 
> i get same result with your patches and my old vlan_bridge way with same codebase...how do i see your problem with the vlan-bridge-way? Do you test with bpi-r2 or only any other board and change r2 to have same DT?

I tested this only on a Bananapi BPI-R2 using the devicetree with this 
series applied on a few days old netdev/net-next.git main tree.

Arınç

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Aw: Re: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[Frank Wunderlich]

Hi

> Gesendet: Samstag, 04. Februar 2023 um 13:12 Uhr
> Von: "Arınç ÜNAL" <arinc.unal@arinc9.com>
> An: "Frank Wunderlich" <frank-w@public-files.de>
> Cc: arinc9.unal@gmail.com, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Matthias Brugger" <matthias.bgg@gmail.com>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, erkin.bozoglu@xeront.com, "Sean Wang" <sean.wang@mediatek.com>, "DENG Qingfang" <dqfext@gmail.com>
> Betreff: Re: Aw: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2
>
> On 4.02.2023 14:43, Frank Wunderlich wrote:
> >> Gesendet: Samstag, 04. Februar 2023 um 11:27 Uhr
> >> Von: "Frank Wunderlich" <frank-w@public-files.de>
> >> An: "Arınç ÜNAL" <arinc.unal@arinc9.com>
> >> Cc: arinc9.unal@gmail.com, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Matthias Brugger" <matthias.bgg@gmail.com>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, erkin.bozoglu@xeront.com, "Sean Wang" <sean.wang@mediatek.com>, "DENG Qingfang" <dqfext@gmail.com>
> >> Betreff: Aw: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2
> >>
> >> Hi aranc,
> >>
> >> have tested this series, basicly it works, but i get only ~620 Mbits/sec (much more i will need on wan) in tx-mode of r2, rx-mode (iperf3 -c IP -R on r2) gets full 939 Mbits/sec. Both no retransmitts.
> >>
> >> tried with my laptop which gets 940Mbit/sec in tx mode too...other end is a R2 with 5.15 connected to lan0 (and eth1+aux enabled, dmesg clean so far...for the "kernel log flooded"-comment).
> >>
> >> maybe gmac1 needs to be tweaked a bit (clock-settings)?
> >>
> >> can you confirm this with your board?
> > 
> > tested the vlan_aware way with 5.15.80 and got better result
> > 
> > ip link add br0 type bridge vlan_filtering 1
> > ip l set aux master br0
> > ip l set wan master br0
> > bridge vlan add vid 99 dev wan
> > bridge vlan add vid 99 dev aux
> > bridge vlan
> > ip l s eth1 up
> > ip l s wan up
> > ip a a 192.168.0.11/24 dev eth1
> > ip l s br0 up
> > ip l s aux up
> > 
> > i see traffic on eth1 increasing and iperf3 shows in both directions ~940Mbit/s, no strange mesages in dmesg while testing...where do you see these?
> 
> You didn't put eth1 on a bridge. I suggest you read my mails with higher 
> attention so both of our time is spent efficiently.

sorry if i misseed this detail, but it was not part of the instructions i got from mtk and did not found it in our mail-conversion. why do i need to add the gmac into the bridge??

the gmac is connected physically to mt7531 p5, and my vlan_aware bridge bridges this port (aux=p5) with wan, 
so i see no need to add eth1 to this bridge too...traffic on wan is tagged with vlan 99 and leaving untagged
on aux which is arriving eth1...

> > tested vlan-way with 6.2 and felix' Patches to more comparable with your test...and got same result (~625Mbit/s in tx and 940Mbit/s in rx-mode=-R on r2)...so it seems anything between 5.15 and 6.2 reduced gmac1 tx bandwidth.
> 
> I don't see an incentive to investigate unless the issue is confirmed on 
> a daily netdev/net-next.git main tree.

have same result on net-next/main with your series, no additional patches on top except adding my build-script and defconfig.

> > 
> > to summarize:
> > 
> > i get same result with your patches and my old vlan_bridge way with same codebase...how do i see your problem with the vlan-bridge-way? Do you test with bpi-r2 or only any other board and change r2 to have same DT?
> 
> I tested this only on a Bananapi BPI-R2 using the devicetree with this 
> series applied on a few days old netdev/net-next.git main tree.

btw. i do this in my currently very limited free time in short chunks, so please forgive me if i miss a detail.

> Arınç

Aw: Re: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[Frank Wunderlich]

Hi

> Gesendet: Samstag, 04. Februar 2023 um 13:12 Uhr
> Von: "Arınç ÜNAL" <arinc.unal@arinc9.com>
> An: "Frank Wunderlich" <frank-w@public-files.de>
> Cc: arinc9.unal@gmail.com, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Matthias Brugger" <matthias.bgg@gmail.com>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, erkin.bozoglu@xeront.com, "Sean Wang" <sean.wang@mediatek.com>, "DENG Qingfang" <dqfext@gmail.com>
> Betreff: Re: Aw: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2
>
> On 4.02.2023 14:43, Frank Wunderlich wrote:
> >> Gesendet: Samstag, 04. Februar 2023 um 11:27 Uhr
> >> Von: "Frank Wunderlich" <frank-w@public-files.de>
> >> An: "Arınç ÜNAL" <arinc.unal@arinc9.com>
> >> Cc: arinc9.unal@gmail.com, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Matthias Brugger" <matthias.bgg@gmail.com>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, erkin.bozoglu@xeront.com, "Sean Wang" <sean.wang@mediatek.com>, "DENG Qingfang" <dqfext@gmail.com>
> >> Betreff: Aw: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2
> >>
> >> Hi aranc,
> >>
> >> have tested this series, basicly it works, but i get only ~620 Mbits/sec (much more i will need on wan) in tx-mode of r2, rx-mode (iperf3 -c IP -R on r2) gets full 939 Mbits/sec. Both no retransmitts.
> >>
> >> tried with my laptop which gets 940Mbit/sec in tx mode too...other end is a R2 with 5.15 connected to lan0 (and eth1+aux enabled, dmesg clean so far...for the "kernel log flooded"-comment).
> >>
> >> maybe gmac1 needs to be tweaked a bit (clock-settings)?
> >>
> >> can you confirm this with your board?
> > 
> > tested the vlan_aware way with 5.15.80 and got better result
> > 
> > ip link add br0 type bridge vlan_filtering 1
> > ip l set aux master br0
> > ip l set wan master br0
> > bridge vlan add vid 99 dev wan
> > bridge vlan add vid 99 dev aux
> > bridge vlan
> > ip l s eth1 up
> > ip l s wan up
> > ip a a 192.168.0.11/24 dev eth1
> > ip l s br0 up
> > ip l s aux up
> > 
> > i see traffic on eth1 increasing and iperf3 shows in both directions ~940Mbit/s, no strange mesages in dmesg while testing...where do you see these?
> 
> You didn't put eth1 on a bridge. I suggest you read my mails with higher 
> attention so both of our time is spent efficiently.

sorry if i misseed this detail, but it was not part of the instructions i got from mtk and did not found it in our mail-conversion. why do i need to add the gmac into the bridge??

the gmac is connected physically to mt7531 p5, and my vlan_aware bridge bridges this port (aux=p5) with wan, 
so i see no need to add eth1 to this bridge too...traffic on wan is tagged with vlan 99 and leaving untagged
on aux which is arriving eth1...

> > tested vlan-way with 6.2 and felix' Patches to more comparable with your test...and got same result (~625Mbit/s in tx and 940Mbit/s in rx-mode=-R on r2)...so it seems anything between 5.15 and 6.2 reduced gmac1 tx bandwidth.
> 
> I don't see an incentive to investigate unless the issue is confirmed on 
> a daily netdev/net-next.git main tree.

have same result on net-next/main with your series, no additional patches on top except adding my build-script and defconfig.

> > 
> > to summarize:
> > 
> > i get same result with your patches and my old vlan_bridge way with same codebase...how do i see your problem with the vlan-bridge-way? Do you test with bpi-r2 or only any other board and change r2 to have same DT?
> 
> I tested this only on a Bananapi BPI-R2 using the devicetree with this 
> series applied on a few days old netdev/net-next.git main tree.

btw. i do this in my currently very limited free time in short chunks, so please forgive me if i miss a detail.

> Arınç

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Aw: Re: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[Arınç ÜNAL]

On 4.02.2023 16:07, Frank Wunderlich wrote:
> Hi
> 
>> Gesendet: Samstag, 04. Februar 2023 um 13:12 Uhr
>> Von: "Arınç ÜNAL" <arinc.unal@arinc9.com>
>> An: "Frank Wunderlich" <frank-w@public-files.de>
>> Cc: arinc9.unal@gmail.com, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Matthias Brugger" <matthias.bgg@gmail.com>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, erkin.bozoglu@xeront.com, "Sean Wang" <sean.wang@mediatek.com>, "DENG Qingfang" <dqfext@gmail.com>
>> Betreff: Re: Aw: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2
>>
>> On 4.02.2023 14:43, Frank Wunderlich wrote:
>>>> Gesendet: Samstag, 04. Februar 2023 um 11:27 Uhr
>>>> Von: "Frank Wunderlich" <frank-w@public-files.de>
>>>> An: "Arınç ÜNAL" <arinc.unal@arinc9.com>
>>>> Cc: arinc9.unal@gmail.com, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Matthias Brugger" <matthias.bgg@gmail.com>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, erkin.bozoglu@xeront.com, "Sean Wang" <sean.wang@mediatek.com>, "DENG Qingfang" <dqfext@gmail.com>
>>>> Betreff: Aw: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2
>>>>
>>>> Hi aranc,
>>>>
>>>> have tested this series, basicly it works, but i get only ~620 Mbits/sec (much more i will need on wan) in tx-mode of r2, rx-mode (iperf3 -c IP -R on r2) gets full 939 Mbits/sec. Both no retransmitts.
>>>>
>>>> tried with my laptop which gets 940Mbit/sec in tx mode too...other end is a R2 with 5.15 connected to lan0 (and eth1+aux enabled, dmesg clean so far...for the "kernel log flooded"-comment).
>>>>
>>>> maybe gmac1 needs to be tweaked a bit (clock-settings)?
>>>>
>>>> can you confirm this with your board?
>>>
>>> tested the vlan_aware way with 5.15.80 and got better result
>>>
>>> ip link add br0 type bridge vlan_filtering 1
>>> ip l set aux master br0
>>> ip l set wan master br0
>>> bridge vlan add vid 99 dev wan
>>> bridge vlan add vid 99 dev aux
>>> bridge vlan
>>> ip l s eth1 up
>>> ip l s wan up
>>> ip a a 192.168.0.11/24 dev eth1
>>> ip l s br0 up
>>> ip l s aux up
>>>
>>> i see traffic on eth1 increasing and iperf3 shows in both directions ~940Mbit/s, no strange mesages in dmesg while testing...where do you see these?
>>
>> You didn't put eth1 on a bridge. I suggest you read my mails with higher
>> attention so both of our time is spent efficiently.
> 
> sorry if i misseed this detail, but it was not part of the instructions i got from mtk and did not found it in our mail-conversion. why do i need to add the gmac into the bridge??

I was going to say, to put the host(s) connected to the wan port on the 
same network as other ports, but using the wan interface for that 
instead would work. Cool, we can cross this off the list.

> 
> the gmac is connected physically to mt7531 p5, and my vlan_aware bridge bridges this port (aux=p5) with wan,
> so i see no need to add eth1 to this bridge too...traffic on wan is tagged with vlan 99 and leaving untagged
> on aux which is arriving eth1...
> 
>>> tested vlan-way with 6.2 and felix' Patches to more comparable with your test...and got same result (~625Mbit/s in tx and 940Mbit/s in rx-mode=-R on r2)...so it seems anything between 5.15 and 6.2 reduced gmac1 tx bandwidth.
>>
>> I don't see an incentive to investigate unless the issue is confirmed on
>> a daily netdev/net-next.git main tree.
> 
> have same result on net-next/main with your series, no additional patches on top except adding my build-script and defconfig.

Finding the cause of reduced network performance is quite a challenging 
task. The only person I know that gives this a serious approach is Rafał 
Miłecki. There are scripts and things they share on the openwrt-devel 
mailing list along with details of their investigation, usually for 
Broadcom SoCs.

I'm no good in this so I'm not going to do anything about it. There are 
issues with the MediaTek ethernet and MT7530 DSA subdriver that 
completely break communication which I want to have them addressed.

Arınç

Re: Aw: Re: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[Arınç ÜNAL]

On 4.02.2023 16:07, Frank Wunderlich wrote:
> Hi
> 
>> Gesendet: Samstag, 04. Februar 2023 um 13:12 Uhr
>> Von: "Arınç ÜNAL" <arinc.unal@arinc9.com>
>> An: "Frank Wunderlich" <frank-w@public-files.de>
>> Cc: arinc9.unal@gmail.com, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Matthias Brugger" <matthias.bgg@gmail.com>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, erkin.bozoglu@xeront.com, "Sean Wang" <sean.wang@mediatek.com>, "DENG Qingfang" <dqfext@gmail.com>
>> Betreff: Re: Aw: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2
>>
>> On 4.02.2023 14:43, Frank Wunderlich wrote:
>>>> Gesendet: Samstag, 04. Februar 2023 um 11:27 Uhr
>>>> Von: "Frank Wunderlich" <frank-w@public-files.de>
>>>> An: "Arınç ÜNAL" <arinc.unal@arinc9.com>
>>>> Cc: arinc9.unal@gmail.com, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Matthias Brugger" <matthias.bgg@gmail.com>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, erkin.bozoglu@xeront.com, "Sean Wang" <sean.wang@mediatek.com>, "DENG Qingfang" <dqfext@gmail.com>
>>>> Betreff: Aw: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2
>>>>
>>>> Hi aranc,
>>>>
>>>> have tested this series, basicly it works, but i get only ~620 Mbits/sec (much more i will need on wan) in tx-mode of r2, rx-mode (iperf3 -c IP -R on r2) gets full 939 Mbits/sec. Both no retransmitts.
>>>>
>>>> tried with my laptop which gets 940Mbit/sec in tx mode too...other end is a R2 with 5.15 connected to lan0 (and eth1+aux enabled, dmesg clean so far...for the "kernel log flooded"-comment).
>>>>
>>>> maybe gmac1 needs to be tweaked a bit (clock-settings)?
>>>>
>>>> can you confirm this with your board?
>>>
>>> tested the vlan_aware way with 5.15.80 and got better result
>>>
>>> ip link add br0 type bridge vlan_filtering 1
>>> ip l set aux master br0
>>> ip l set wan master br0
>>> bridge vlan add vid 99 dev wan
>>> bridge vlan add vid 99 dev aux
>>> bridge vlan
>>> ip l s eth1 up
>>> ip l s wan up
>>> ip a a 192.168.0.11/24 dev eth1
>>> ip l s br0 up
>>> ip l s aux up
>>>
>>> i see traffic on eth1 increasing and iperf3 shows in both directions ~940Mbit/s, no strange mesages in dmesg while testing...where do you see these?
>>
>> You didn't put eth1 on a bridge. I suggest you read my mails with higher
>> attention so both of our time is spent efficiently.
> 
> sorry if i misseed this detail, but it was not part of the instructions i got from mtk and did not found it in our mail-conversion. why do i need to add the gmac into the bridge??

I was going to say, to put the host(s) connected to the wan port on the 
same network as other ports, but using the wan interface for that 
instead would work. Cool, we can cross this off the list.

> 
> the gmac is connected physically to mt7531 p5, and my vlan_aware bridge bridges this port (aux=p5) with wan,
> so i see no need to add eth1 to this bridge too...traffic on wan is tagged with vlan 99 and leaving untagged
> on aux which is arriving eth1...
> 
>>> tested vlan-way with 6.2 and felix' Patches to more comparable with your test...and got same result (~625Mbit/s in tx and 940Mbit/s in rx-mode=-R on r2)...so it seems anything between 5.15 and 6.2 reduced gmac1 tx bandwidth.
>>
>> I don't see an incentive to investigate unless the issue is confirmed on
>> a daily netdev/net-next.git main tree.
> 
> have same result on net-next/main with your series, no additional patches on top except adding my build-script and defconfig.

Finding the cause of reduced network performance is quite a challenging 
task. The only person I know that gives this a serious approach is Rafał 
Miłecki. There are scripts and things they share on the openwrt-devel 
mailing list along with details of their investigation, usually for 
Broadcom SoCs.

I'm no good in this so I'm not going to do anything about it. There are 
issues with the MediaTek ethernet and MT7530 DSA subdriver that 
completely break communication which I want to have them addressed.

Arınç

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[Arınç ÜNAL]

OK, hold this patch series, I'm going to send v3 soon with enabling both 
CPU ports to support changing the DSA master. We've got developments on 
the MediaTek ethernet driver and MT7530 DSA subdriver that surpassed my 
expectations.

Arınç

On 1.02.2023 21:56, arinc9.unal@gmail.com wrote:
> From: Arınç ÜNAL <arinc.unal@arinc9.com>
> 
> Mux the MT7530 switch's phy0 to gmac5 which is wired to the SoC's gmac1.
> This achieves 2 Gbps total bandwidth to the CPU using the second RGMII.
> 
> With this, the interface name to access phy0 changes from wan to eth1.
> 
> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
> ---
>   arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 15 ++++++++++-----
>   1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> index dc9b4f99eb8b..64700253fd35 100644
> --- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> +++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> @@ -182,6 +182,12 @@ fixed-link {
>   	};
>   };
>   
> +&gmac1 {
> +	status = "okay";
> +	phy-mode = "rgmii";
> +	phy-handle = <&ethphy0>;
> +};
> +
>   &eth {
>   	status = "okay";
>   
> @@ -189,6 +195,10 @@ mdio-bus {
>   		#address-cells = <1>;
>   		#size-cells = <0>;
>   
> +		ethphy0: ethernet-phy@0 {
> +			reg = <0>;
> +		};
> +
>   		switch@1f {
>   			compatible = "mediatek,mt7530";
>   			reg = <0x1f>;
> @@ -200,11 +210,6 @@ ports {
>   				#address-cells = <1>;
>   				#size-cells = <0>;
>   
> -				port@0 {
> -					reg = <0>;
> -					label = "wan";
> -				};
> -
>   				port@1 {
>   					reg = <1>;
>   					label = "lan0";

Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[Arınç ÜNAL]

OK, hold this patch series, I'm going to send v3 soon with enabling both 
CPU ports to support changing the DSA master. We've got developments on 
the MediaTek ethernet driver and MT7530 DSA subdriver that surpassed my 
expectations.

Arınç

On 1.02.2023 21:56, arinc9.unal@gmail.com wrote:
> From: Arınç ÜNAL <arinc.unal@arinc9.com>
> 
> Mux the MT7530 switch's phy0 to gmac5 which is wired to the SoC's gmac1.
> This achieves 2 Gbps total bandwidth to the CPU using the second RGMII.
> 
> With this, the interface name to access phy0 changes from wan to eth1.
> 
> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
> ---
>   arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 15 ++++++++++-----
>   1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> index dc9b4f99eb8b..64700253fd35 100644
> --- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> +++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> @@ -182,6 +182,12 @@ fixed-link {
>   	};
>   };
>   
> +&gmac1 {
> +	status = "okay";
> +	phy-mode = "rgmii";
> +	phy-handle = <&ethphy0>;
> +};
> +
>   &eth {
>   	status = "okay";
>   
> @@ -189,6 +195,10 @@ mdio-bus {
>   		#address-cells = <1>;
>   		#size-cells = <0>;
>   
> +		ethphy0: ethernet-phy@0 {
> +			reg = <0>;
> +		};
> +
>   		switch@1f {
>   			compatible = "mediatek,mt7530";
>   			reg = <0x1f>;
> @@ -200,11 +210,6 @@ ports {
>   				#address-cells = <1>;
>   				#size-cells = <0>;
>   
> -				port@0 {
> -					reg = <0>;
> -					label = "wan";
> -				};
> -
>   				port@1 {
>   					reg = <1>;
>   					label = "lan0";

Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[Arınç ÜNAL]

OK, hold this patch series, I'm going to send v3 soon with enabling both 
CPU ports to support changing the DSA master. We've got developments on 
the MediaTek ethernet driver and MT7530 DSA subdriver that surpassed my 
expectations.

Arınç

On 1.02.2023 21:56, arinc9.unal@gmail.com wrote:
> From: Arınç ÜNAL <arinc.unal@arinc9.com>
> 
> Mux the MT7530 switch's phy0 to gmac5 which is wired to the SoC's gmac1.
> This achieves 2 Gbps total bandwidth to the CPU using the second RGMII.
> 
> With this, the interface name to access phy0 changes from wan to eth1.
> 
> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
> ---
>   arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 15 ++++++++++-----
>   1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> index dc9b4f99eb8b..64700253fd35 100644
> --- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> +++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> @@ -182,6 +182,12 @@ fixed-link {
>   	};
>   };
>   
> +&gmac1 {
> +	status = "okay";
> +	phy-mode = "rgmii";
> +	phy-handle = <&ethphy0>;
> +};
> +
>   &eth {
>   	status = "okay";
>   
> @@ -189,6 +195,10 @@ mdio-bus {
>   		#address-cells = <1>;
>   		#size-cells = <0>;
>   
> +		ethphy0: ethernet-phy@0 {
> +			reg = <0>;
> +		};
> +
>   		switch@1f {
>   			compatible = "mediatek,mt7530";
>   			reg = <0x1f>;
> @@ -200,11 +210,6 @@ ports {
>   				#address-cells = <1>;
>   				#size-cells = <0>;
>   
> -				port@0 {
> -					reg = <0>;
> -					label = "wan";
> -				};
> -
>   				port@1 {
>   					reg = <1>;
>   					label = "lan0";

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel