Γεια σας και πάλι!
We're doing cleanup and adding port@5 as a CPU port.
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 us in on this.
I've tested the CPU ports on my Bananapi BPI-R2. DTs compile fine.
v3:
- Drop phy muxing, add port@5 as a CPU port instead.
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 ð 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: enable flow control on port@6
arm: dts: mt7623: add port@5 as CPU port
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 | 99 ++++++++++++++++++++++
arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 49 ++++++++---
arch/arm/boot/dts/mt7623n-rfb-emmc.dts | 37 ++++----
6 files changed, 207 insertions(+), 162 deletions(-)
From: Arınç ÜNAL <[email protected]>
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 ð on the
DTs that call mt7623.dtsi. Remove the unnecessary mdio label from Bananapi
BPI-R2.
Signed-off-by: Arınç ÜNAL <[email protected]>
---
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";
};
-ð {
+&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;
};
+};
+
+ð {
+ 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";
};
-ð {
+&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;
};
+};
+
+ð {
+ 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 {
};
};
-ð {
+&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;
};
+};
+
+ð {
+ 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 {
};
};
-ð {
+&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>;
+};
+
+ð {
+ status = "okay";
mdio-bus {
#address-cells = <1>;
--
2.37.2
From: Arınç ÜNAL <[email protected]>
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 <[email protected]>
---
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";
+ };
-ð {
- 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 = <ðsys 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";
+ };
-ð {
- 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 = <ðsys 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;
+ };
+};
+
ð {
+ 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 = <ðsys 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
From: Arınç ÜNAL <[email protected]>
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 <[email protected]>
---
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 = <ðsys 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
From: Arınç ÜNAL <[email protected]>
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 <[email protected]>
---
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
From: Arınç ÜNAL <[email protected]>
On the MT7623AI SoC and Bananapi BPI-R2, port 5 of the MT7530 switch is
connected to the second MAC of the SoC as a CPU port. Add the port and set
up the second MAC on the bindings.
Signed-off-by: Arınç ÜNAL <[email protected]>
---
arch/arm/boot/dts/mt7623a.dtsi | 24 +++++++++++++++++++
arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 24 +++++++++++++++++++
2 files changed, 48 insertions(+)
diff --git a/arch/arm/boot/dts/mt7623a.dtsi b/arch/arm/boot/dts/mt7623a.dtsi
index 2a50b5c0c933..bcf909d58a1c 100644
--- a/arch/arm/boot/dts/mt7623a.dtsi
+++ b/arch/arm/boot/dts/mt7623a.dtsi
@@ -28,6 +28,17 @@ fixed-link {
};
};
+&gmac1 {
+ status = "okay";
+ phy-mode = "rgmii";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
+};
+
ð {
status = "okay";
power-domains = <&scpsys MT7623A_POWER_DOMAIN_ETH>;
@@ -79,6 +90,19 @@ port@4 {
label = "swp4";
};
+ port@5 {
+ reg = <5>;
+ label = "cpu";
+ ethernet = <&gmac1>;
+ phy-mode = "rgmii";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
+ };
+
port@6 {
reg = <6>;
label = "cpu";
diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
index dc9b4f99eb8b..642b1c0a96ba 100644
--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
@@ -182,6 +182,17 @@ fixed-link {
};
};
+&gmac1 {
+ status = "okay";
+ phy-mode = "rgmii";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
+};
+
ð {
status = "okay";
@@ -225,6 +236,19 @@ port@4 {
label = "lan3";
};
+ port@5 {
+ reg = <5>;
+ label = "cpu";
+ ethernet = <&gmac1>;
+ phy-mode = "rgmii";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
+ };
+
port@6 {
reg = <6>;
label = "cpu";
--
2.37.2
Frank, I think Matthias is waiting for your approval on this patch
series. Is this series fine by you?
Arınç
Hi,
finally get some time to bootup with this series on my r2.
I see that inserting the port@5 as cpu-port maps this as default-cpu because dsa-core uses first found cpu-port as
default (dsa_tree_setup_cpu_ports in dsa.c) and because of lower bandwidth (rgmii instead of trgmii) not the best choice.
But it look worse...network is currently broken (set both gmacs up).
I see arp-packets reaching remote side, but reponse is not received by r2
I have tested it on 6.2-rc8 (wan-port), maybe additional patches are needed?...userspace setup should be right.
so i added series on top of net-next (no additional patches except some basic like build-script,defconfig and such)...same result...
i'm not sure if i change the mapping from userspace back to eth0, so disabled port@5 in switch, now port6 is
cpu-port again and it works...so something is wrong with port5 of switch or gmac1.
regards Frank
On 18.02.2023 13:24, Frank Wunderlich wrote:
> Hi,
>
> finally get some time to bootup with this series on my r2.
>
> I see that inserting the port@5 as cpu-port maps this as default-cpu because dsa-core uses first found cpu-port as
> default (dsa_tree_setup_cpu_ports in dsa.c) and because of lower bandwidth (rgmii instead of trgmii) not the best choice.
>
> But it look worse...network is currently broken (set both gmacs up).
> I see arp-packets reaching remote side, but reponse is not received by r2
>
> I have tested it on 6.2-rc8 (wan-port), maybe additional patches are needed?...userspace setup should be right.
>
> so i added series on top of net-next (no additional patches except some basic like build-script,defconfig and such)...same result...
>
> i'm not sure if i change the mapping from userspace back to eth0, so disabled port@5 in switch, now port6 is
> cpu-port again and it works...so something is wrong with port5 of switch or gmac1.
That's a driver issue and will be fixed once an accepted version of
these patches [0] [1] [2] are applied to net-next. You should have them
on your inbox, I specifically told Richard to CC you.
This is devicetree bindings. We're here to describe the hardware. The
way a driver works should not affect describing the hardware.
To address the lower bandwidth situation you mentioned, a devicetree
property to designate a CPU port as the default CPU port could be
introduced. I'm not aware of a similar conversation so I'll send a mail
to netdev to discuss this. Will CC you.
[0]
https://lore.kernel.org/netdev/[email protected]/
[1]
https://lore.kernel.org/netdev/[email protected]/
[2]
https://lore.kernel.org/netdev/[email protected]/
Arınç
Hi,
> Gesendet: Samstag, 18. Februar 2023 um 11:49 Uhr
> Von: "Arınç ÜNAL" <[email protected]>
> An: "Frank Wunderlich" <[email protected]>
> On 18.02.2023 13:24, Frank Wunderlich wrote:
> > Hi,
> >
> > finally get some time to bootup with this series on my r2.
> >
> > I see that inserting the port@5 as cpu-port maps this as default-cpu because dsa-core uses first found cpu-port as
> > default (dsa_tree_setup_cpu_ports in dsa.c) and because of lower bandwidth (rgmii instead of trgmii) not the best choice.
> >
> > But it look worse...network is currently broken (set both gmacs up).
> > I see arp-packets reaching remote side, but reponse is not received by r2
> >
> > I have tested it on 6.2-rc8 (wan-port), maybe additional patches are needed?...userspace setup should be right.
> >
> > so i added series on top of net-next (no additional patches except some basic like build-script,defconfig and such)...same result...
> >
> > i'm not sure if i change the mapping from userspace back to eth0, so disabled port@5 in switch, now port6 is
> > cpu-port again and it works...so something is wrong with port5 of switch or gmac1.
>
> That's a driver issue and will be fixed once an accepted version of
> these patches [0] [1] [2] are applied to net-next. You should have them
> on your inbox, I specifically told Richard to CC you.
yes, i've got them, but not applied when starting these tests. Not thought, that this change is necessary
as we use both gmac on mt7531/bpi-r3 with out problems.
with these 3 Patches network-connection works, but only at ~624 Mbit/s in TX-Mode (started iperf3-client on r2 without -R) and massive retransmitts on first run, other direction is clean.
and these Patches need to be applied first (when fixed up) else network is broken.
> This is devicetree bindings. We're here to describe the hardware. The
> way a driver works should not affect describing the hardware.
thats right, but it should not break/change behaviour like now all ports have only ~600Mbit because of
moving them all to the other gmac which has obvious issues.
> To address the lower bandwidth situation you mentioned, a devicetree
> property to designate a CPU port as the default CPU port could be
> introduced. I'm not aware of a similar conversation so I'll send a mail
> to netdev to discuss this. Will CC you.
isn't there a way to leave ports by default on the the better gmac (gmac0=trgmii)?
maybe moving port5 below port6...not nice, but then port6 is the first cpu found.
or maybe defined the default cpu in driver which gets picked up by core (define port6 if available as default).
Imho additional dts-propperty is wrong approch...it should be handled by driver. But cpu-port-selection is
currently done in dsa-core which makes it a bit difficult.
I'm not sure how the multi-cpu support in dsa-core ended and how you use the other gmac not used by dsa-core
set master in userspace-config? i remember you've sent a patch adding callback for it.
imho dts change should be applied if these points are cleared...
regards Frank
On 18.02.2023 15:18, Frank Wunderlich wrote:
> Hi,
>
>> Gesendet: Samstag, 18. Februar 2023 um 11:49 Uhr
>> Von: "Arınç ÜNAL" <[email protected]>
>> An: "Frank Wunderlich" <[email protected]>
>
>> On 18.02.2023 13:24, Frank Wunderlich wrote:
>>> Hi,
>>>
>>> finally get some time to bootup with this series on my r2.
>>>
>>> I see that inserting the port@5 as cpu-port maps this as default-cpu because dsa-core uses first found cpu-port as
>>> default (dsa_tree_setup_cpu_ports in dsa.c) and because of lower bandwidth (rgmii instead of trgmii) not the best choice.
>>>
>>> But it look worse...network is currently broken (set both gmacs up).
>>> I see arp-packets reaching remote side, but reponse is not received by r2
>>>
>>> I have tested it on 6.2-rc8 (wan-port), maybe additional patches are needed?...userspace setup should be right.
>>>
>>> so i added series on top of net-next (no additional patches except some basic like build-script,defconfig and such)...same result...
>>>
>>> i'm not sure if i change the mapping from userspace back to eth0, so disabled port@5 in switch, now port6 is
>>> cpu-port again and it works...so something is wrong with port5 of switch or gmac1.
>>
>> That's a driver issue and will be fixed once an accepted version of
>> these patches [0] [1] [2] are applied to net-next. You should have them
>> on your inbox, I specifically told Richard to CC you.
>
> yes, i've got them, but not applied when starting these tests. Not thought, that this change is necessary
> as we use both gmac on mt7531/bpi-r3 with out problems.
>
> with these 3 Patches network-connection works, but only at ~624 Mbit/s in TX-Mode (started iperf3-client on r2 without -R) and massive retransmitts on first run, other direction is clean.
Ok, so according to your tests, traffic through gmac1 is not very good.
gmac0 should be the default DSA master.
By the way, did you make a bug report of this, by sending a mail to
netdev mailing list or some other way?
>
> and these Patches need to be applied first (when fixed up) else network is broken.
That's true.
>
>> This is devicetree bindings. We're here to describe the hardware. The
>> way a driver works should not affect describing the hardware.
>
> thats right, but it should not break/change behaviour like now all ports have only ~600Mbit because of
> moving them all to the other gmac which has obvious issues.
Makes sense.
>
>> To address the lower bandwidth situation you mentioned, a devicetree
>> property to designate a CPU port as the default CPU port could be
>> introduced. I'm not aware of a similar conversation so I'll send a mail
>> to netdev to discuss this. Will CC you.
>
> isn't there a way to leave ports by default on the the better gmac (gmac0=trgmii)?
> maybe moving port5 below port6...not nice, but then port6 is the first cpu found.
This could be done but it comes off as an improper way to me.
> or maybe defined the default cpu in driver which gets picked up by core (define port6 if available as default).
> Imho additional dts-propperty is wrong approch...it should be handled by driver. But cpu-port-selection is
> currently done in dsa-core which makes it a bit difficult.
>
> I'm not sure how the multi-cpu support in dsa-core ended and how you use the other gmac not used by dsa-core
>
> set master in userspace-config? i remember you've sent a patch adding callback for it.
You can change the DSA master using iproute2-6.1.0 and above with this
patch which should be in your inbox as well.
https://lore.kernel.org/netdev/[email protected]/
>
> imho dts change should be applied if these points are cleared...
The only issue I see here is that, with this patch series, port5 becomes
the default CPU port which is not preferred for the reasons you explained.
So once we can have port6 to be the default CPU port of the DSA slaves,
there's no issues left.
Arınç
Am 18. Februar 2023 18:02:11 MEZ schrieb "Arınç ÜNAL" <[email protected]>:
>On 18.02.2023 15:18, Frank Wunderlich wrote:
>> Hi,
>>
>>> Gesendet: Samstag, 18. Februar 2023 um 11:49 Uhr
>>> Von: "Arınç ÜNAL" <[email protected]>
>>> An: "Frank Wunderlich" <[email protected]>
>>
>>> On 18.02.2023 13:24, Frank Wunderlich wrote:
>Ok, so according to your tests, traffic through gmac1 is not very good. gmac0 should be the default DSA master.
>By the way, did you make a bug report of this, by sending a mail to netdev mailing list or some other way?
No,not yet, because gmac1 is not yet used and i had very limited time. I'm not sure it is an issue in mt7530 driver or mtk_soc_eth, not idea how to figure this out. Maybe it can be fixed with a delayed rgmii phy-mode (rgmii-rx-id i guess as traffic affected is rx on switch,tx on gmac).
>> isn't there a way to leave ports by default on the the better gmac (gmac0=trgmii)?
>> maybe moving port5 below port6...not nice, but then port6 is the first cpu found.
>
>This could be done but it comes off as an improper way to me.
Just thought about a way without the need of changing driver or adding a new dt property which can be wrongly used (who prevents anybody set the "default-cpu" property on more than 1 cpu-port?), Or define it at switch node level not port level (e.g. via phandle).
If the 5-below-6 way is not the right one i would prefer a driver solution, e.g. let driver choose the best cpu based on fixed value (constant via define) or on highest throughput (trgmii > rgmii),but last may fail if both cpu-ports have same speed like mt7531.
These are the possible solutions i see atm. Maybe dsa people can share their opinion.
>> set master in userspace-config? i remember you've sent a patch adding callback for it.
>
>You can change the DSA master using iproute2-6.1.0 and above with this patch which should be in your inbox as well.
>
>https://lore.kernel.org/netdev/[email protected]/
I try to test it.
>The only issue I see here is that, with this patch series, port5 becomes the default CPU port which is not preferred for the reasons you explained.
>
>So once we can have port6 to be the default CPU port of the DSA slaves, there's no issues left.
For me this would be ok if the current configuration does not change, right :)
Thx for your work.
regards Frank
On 18.02.2023 22:11, Frank Wunderlich wrote:
> Am 18. Februar 2023 18:02:11 MEZ schrieb "Arınç ÜNAL" <[email protected]>:
>> On 18.02.2023 15:18, Frank Wunderlich wrote:
>>> Hi,
>>>
>>>> Gesendet: Samstag, 18. Februar 2023 um 11:49 Uhr
>>>> Von: "Arınç ÜNAL" <[email protected]>
>>>> An: "Frank Wunderlich" <[email protected]>
>>>
>>>> On 18.02.2023 13:24, Frank Wunderlich wrote:
>
>> Ok, so according to your tests, traffic through gmac1 is not very good. gmac0 should be the default DSA master.
>
>> By the way, did you make a bug report of this, by sending a mail to netdev mailing list or some other way?
>
> No,not yet, because gmac1 is not yet used and i had very limited time. I'm not sure it is an issue in mt7530 driver or mtk_soc_eth, not idea how to figure this out. Maybe it can be fixed with a delayed rgmii phy-mode (rgmii-rx-id i guess as traffic affected is rx on switch,tx on gmac).
My experience with rgmii delays is that if the correct delay is not set
for tx or rx, that tx or rx will just not work at all. But testing it
anyway won't hurt.
Can you also remove this from mt7530.c and do the test again? See if the
performance changes at all.
/* Set core clock into 500Mhz */
core_write(priv, CORE_GSWPLL_GRP2,
RG_GSWPLL_POSDIV_500M(1) |
RG_GSWPLL_FBKDIV_500M(25));
>
>>> isn't there a way to leave ports by default on the the better gmac (gmac0=trgmii)?
>>> maybe moving port5 below port6...not nice, but then port6 is the first cpu found.
>>
>> This could be done but it comes off as an improper way to me.
>
> Just thought about a way without the need of changing driver or adding a new dt property which can be wrongly used (who prevents anybody set the "default-cpu" property on more than 1 cpu-port?), Or define it at switch node level not port level (e.g. via phandle).
This is why we write json-schema documentation.
>
> If the 5-below-6 way is not the right one i would prefer a driver solution, e.g. let driver choose the best cpu based on fixed value (constant via define) or on highest throughput (trgmii > rgmii),but last may fail if both cpu-ports have same speed like mt7531.
>
> These are the possible solutions i see atm. Maybe dsa people can share their opinion.
You should share your opinion on my mail to netdev mailing list I
recently CC'd you.
>
>>> set master in userspace-config? i remember you've sent a patch adding callback for it.
>>
>> You can change the DSA master using iproute2-6.1.0 and above with this patch which should be in your inbox as well.
>>
>> https://lore.kernel.org/netdev/[email protected]/
>
> I try to test it.
>
>> The only issue I see here is that, with this patch series, port5 becomes the default CPU port which is not preferred for the reasons you explained.
>>
>> So once we can have port6 to be the default CPU port of the DSA slaves, there's no issues left.
>
> For me this would be ok if the current configuration does not change, right :)
Userspace configuration won't change, not with the current patch, not ever.
Arınç
> Gesendet: Samstag, 18. Februar 2023 um 20:34 Uhr
> Von: "Arınç ÜNAL" <[email protected]>
> An: [email protected]
> On 18.02.2023 22:11, Frank Wunderlich wrote:
> > Am 18. Februar 2023 18:02:11 MEZ schrieb "Arınç ÜNAL" <[email protected]>:
> >> On 18.02.2023 15:18, Frank Wunderlich wrote:
> Can you also remove this from mt7530.c and do the test again? See if the
> performance changes at all.
>
> /* Set core clock into 500Mhz */
> core_write(priv, CORE_GSWPLL_GRP2,
> RG_GSWPLL_POSDIV_500M(1) |
> RG_GSWPLL_FBKDIV_500M(25));
>
with these disabled i have a bit better performance (625 Mbits/sec instead of 600) and no retransmitts on first iperf3-run.
not yet tried any rgmii-delay option (have no idea which is the right one on which position), but yes, mostly it does not improve performance...it simply does work or does not work.
regards Frank
Hi,
retested series on bananpi r2 on 6.3-rc6 (after throughput is fixed for mt7623/trgmii too) with additional patches:
"net: dsa: implement preferred cpu port handling" by Vladimir Oltean to stay on gmac0 by default
"net: dsa: mt7530: add support for changing DSA master" by Richard van Schagen
looks good so far, but i have not managed how to change dsa master from the preferred port (eth0) to the second one...
any idea how the correct syntax is for iproute2?
at least vladimirs patch should be included when applying this series
regards Frank
On 12.04.2023 15:49, Frank Wunderlich wrote:
> Hi,
>
> retested series on bananpi r2 on 6.3-rc6 (after throughput is fixed for mt7623/trgmii too) with additional patches:
>
> "net: dsa: implement preferred cpu port handling" by Vladimir Oltean to stay on gmac0 by default
> "net: dsa: mt7530: add support for changing DSA master" by Richard van Schagen
>
> looks good so far, but i have not managed how to change dsa master from the preferred port (eth0) to the second one...
> any idea how the correct syntax is for iproute2?
https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html#affinity-of-user-ports-to-cpu-ports
In short: ip link set lan0 type dsa conduit eth1
>
> at least vladimirs patch should be included when applying this series
I'm currently cleaning up the DSA driver, I'll get to this at some point.
Arınç
Hi
> Gesendet: Mittwoch, 12. April 2023 um 16:31 Uhr
> Von: "Arınç ÜNAL" <[email protected]>
> > looks good so far, but i have not managed how to change dsa master from the preferred port (eth0) to the second one...
> > any idea how the correct syntax is for iproute2?
>
> https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html#affinity-of-user-ports-to-cpu-ports
>
> In short: ip link set lan0 type dsa conduit eth1
thanks, it changes the master when i upgrade iproute to 6.1 (from debian bullseye-backports), but i cannot do any traffic on it after switching to gmac1...
5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff
inet 192.168.0.11/24 scope global wan
valid_lft forever preferred_lft forever
see no p5-TX/gmac-rx
root@bpi-r2:~# ethtool -S eth1
NIC statistics:
tx_bytes: 5156
tx_packets: 61
tx_skip: 0
tx_collisions: 0
rx_bytes: 0
rx_packets: 0
rx_overflow: 0
rx_fcs_errors: 0
rx_short_errors: 0
rx_long_errors: 0
rx_checksum_errors: 0
rx_flow_control_packets: 0
rx_xdp_redirect: 0
rx_xdp_pass: 0
rx_xdp_drop: 0
rx_xdp_tx: 0
rx_xdp_tx_errors: 0
tx_xdp_xmit: 0
tx_xdp_xmit_errors: 0
p05_TxDrop: 0
p05_TxCrcErr: 0
p05_TxUnicast: 0
p05_TxMulticast: 0
p05_TxBroadcast: 0
p05_TxCollision: 0
p05_TxSingleCollision: 0
p05_TxMultipleCollision: 0
p05_TxDeferred: 0
p05_TxLateCollision: 0
p05_TxExcessiveCollistion: 0
p05_TxPause: 0
p05_TxPktSz64: 0
p05_TxPktSz65To127: 0
p05_TxPktSz128To255: 0
p05_TxPktSz256To511: 0
p05_TxPktSz512To1023: 0
p05_Tx1024ToMax: 0
p05_TxBytes: 0
p05_RxDrop: 0
p05_RxFiltering: 16
p05_RxUnicast: 11
p05_RxMulticast: 38
p05_RxBroadcast: 12
p05_RxAlignErr: 0
p05_RxCrcErr: 0
p05_RxUnderSizeErr: 0
p05_RxFragErr: 0
p05_RxOverSzErr: 0
p05_RxJabberErr: 0
p05_RxPause: 0
p05_RxPktSz64: 17
p05_RxPktSz65To127: 44
p05_RxPktSz128To255: 0
p05_RxPktSz256To511: 0
p05_RxPktSz512To1023: 0
p05_RxPktSz1024ToMax: 0
p05_RxBytes: 5156
p05_RxCtrlDrop: 0
p05_RxIngressDrop: 0
p05_RxArlDrop: 0
maybe i miss something?
i'm not sure it is a problem with richards Patch or p5/gmac1
> > at least vladimirs patch should be included when applying this series
>
> I'm currently cleaning up the DSA driver, I'll get to this at some point.
regards Frank
On 12.04.2023 18:11, Frank Wunderlich wrote:
> Hi
>
>> Gesendet: Mittwoch, 12. April 2023 um 16:31 Uhr
>> Von: "Arınç ÜNAL" <[email protected]>
>>> looks good so far, but i have not managed how to change dsa master from the preferred port (eth0) to the second one...
>>> any idea how the correct syntax is for iproute2?
>>
>> https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html#affinity-of-user-ports-to-cpu-ports
>>
>> In short: ip link set lan0 type dsa conduit eth1
>
> thanks, it changes the master when i upgrade iproute to 6.1 (from debian bullseye-backports), but i cannot do any traffic on it after switching to gmac1...
>
> 5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
> link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.11/24 scope global wan
> valid_lft forever preferred_lft forever
>
> see no p5-TX/gmac-rx
>
> root@bpi-r2:~# ethtool -S eth1
> NIC statistics:
> tx_bytes: 5156
> tx_packets: 61
> tx_skip: 0
> tx_collisions: 0
> rx_bytes: 0
> rx_packets: 0
> rx_overflow: 0
> rx_fcs_errors: 0
> rx_short_errors: 0
> rx_long_errors: 0
> rx_checksum_errors: 0
> rx_flow_control_packets: 0
> rx_xdp_redirect: 0
> rx_xdp_pass: 0
> rx_xdp_drop: 0
> rx_xdp_tx: 0
> rx_xdp_tx_errors: 0
> tx_xdp_xmit: 0
> tx_xdp_xmit_errors: 0
> p05_TxDrop: 0
> p05_TxCrcErr: 0
> p05_TxUnicast: 0
> p05_TxMulticast: 0
> p05_TxBroadcast: 0
> p05_TxCollision: 0
> p05_TxSingleCollision: 0
> p05_TxMultipleCollision: 0
> p05_TxDeferred: 0
> p05_TxLateCollision: 0
> p05_TxExcessiveCollistion: 0
> p05_TxPause: 0
> p05_TxPktSz64: 0
> p05_TxPktSz65To127: 0
> p05_TxPktSz128To255: 0
> p05_TxPktSz256To511: 0
> p05_TxPktSz512To1023: 0
> p05_Tx1024ToMax: 0
> p05_TxBytes: 0
> p05_RxDrop: 0
> p05_RxFiltering: 16
> p05_RxUnicast: 11
> p05_RxMulticast: 38
> p05_RxBroadcast: 12
> p05_RxAlignErr: 0
> p05_RxCrcErr: 0
> p05_RxUnderSizeErr: 0
> p05_RxFragErr: 0
> p05_RxOverSzErr: 0
> p05_RxJabberErr: 0
> p05_RxPause: 0
> p05_RxPktSz64: 17
> p05_RxPktSz65To127: 44
> p05_RxPktSz128To255: 0
> p05_RxPktSz256To511: 0
> p05_RxPktSz512To1023: 0
> p05_RxPktSz1024ToMax: 0
> p05_RxBytes: 5156
> p05_RxCtrlDrop: 0
> p05_RxIngressDrop: 0
> p05_RxArlDrop: 0
>
> maybe i miss something?
>
> i'm not sure it is a problem with richards Patch or p5/gmac1
Did you apply the vlan and flooding fix patches from Richard?
Arınç
Hi
> Gesendet: Mittwoch, 12. April 2023 um 18:21 Uhr
> Von: "Arınç ÜNAL" <[email protected]>
> > thanks, it changes the master when i upgrade iproute to 6.1 (from debian bullseye-backports), but i cannot do any traffic on it after switching to gmac1...
> >
> > 5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
> > link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff
> > inet 192.168.0.11/24 scope global wan
> > valid_lft forever preferred_lft forever
> >
> > see no p5-TX/gmac-rx
> Did you apply the vlan and flooding fix patches from Richard?
have now applied all patches i've found from richard (which are all rejected):
fe4495bb3cc2 2023-02-12 Fix setting up CPU and User ports to be in the correct mode during setup and when toggling vlan_filtering on a bridge port. (HEAD -> 6.3-rc)
b0641f3e1a69 2023-02-12 Fix Flooding: Disable by default on User ports and Enable on CPU ports
cb04b3451524 2023-02-12 Do not add all User ports to the CPU by default. This will break Multi CPU when added a seperate patch. It will be overwritten by .port_enable and since we are forcing output to a port via the Special Tag this is not needed.
and now it seems working and is clear ;)
root@bpi-r2:~# ip l show wan
5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff
iperf3
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.09 GBytes 940 Mbits/sec 0 sender
[ 5] 0.00-10.03 sec 1.09 GBytes 936 Mbits/sec receiver
iperf3 -R
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.04 sec 1.09 GBytes 936 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.09 GBytes 938 Mbits/sec receiver
how do you deal with these patches? do you include them into your mt7530 fixes series? they (and vladimirs preferred cpu-port) need to be applied before these DTS-changes
regards Frank
On 12.04.2023 19:53, Frank Wunderlich wrote:
> Hi
>
>> Gesendet: Mittwoch, 12. April 2023 um 18:21 Uhr
>> Von: "Arınç ÜNAL" <[email protected]>
>>> thanks, it changes the master when i upgrade iproute to 6.1 (from debian bullseye-backports), but i cannot do any traffic on it after switching to gmac1...
>>>
>>> 5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
>>> link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff
>>> inet 192.168.0.11/24 scope global wan
>>> valid_lft forever preferred_lft forever
>>>
>>> see no p5-TX/gmac-rx
>
>> Did you apply the vlan and flooding fix patches from Richard?
>
> have now applied all patches i've found from richard (which are all rejected):
>
> fe4495bb3cc2 2023-02-12 Fix setting up CPU and User ports to be in the correct mode during setup and when toggling vlan_filtering on a bridge port. (HEAD -> 6.3-rc)
> b0641f3e1a69 2023-02-12 Fix Flooding: Disable by default on User ports and Enable on CPU ports
> cb04b3451524 2023-02-12 Do not add all User ports to the CPU by default. This will break Multi CPU when added a seperate patch. It will be overwritten by .port_enable and since we are forcing output to a port via the Special Tag this is not needed.
>
> and now it seems working and is clear ;)
>
> root@bpi-r2:~# ip l show wan
> 5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
> link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff
>
> iperf3
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-10.00 sec 1.09 GBytes 940 Mbits/sec 0 sender
> [ 5] 0.00-10.03 sec 1.09 GBytes 936 Mbits/sec receiver
>
>
> iperf3 -R
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-10.04 sec 1.09 GBytes 936 Mbits/sec 0 sender
> [ 5] 0.00-10.00 sec 1.09 GBytes 938 Mbits/sec receiver
>
>
> how do you deal with these patches? do you include them into your mt7530 fixes series? they (and vladimirs preferred cpu-port) need to be applied before these DTS-changes
Dealing with this is the last step on my tasklist. Take a look:
https://arinc9.notion.site/mt7530-c-improvements-bbfdc2ceb958484b9627297b88bc6d4a
Arınç
On 12/04/2023 19:06, Arınç ÜNAL wrote:
> On 12.04.2023 19:53, Frank Wunderlich wrote:
>> Hi
>>
>>> Gesendet: Mittwoch, 12. April 2023 um 18:21 Uhr
>>> Von: "Arınç ÜNAL" <[email protected]>
>>>> thanks, it changes the master when i upgrade iproute to 6.1 (from debian
>>>> bullseye-backports), but i cannot do any traffic on it after switching to
>>>> gmac1...
>>>>
>>>> 5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
>>>> UP group default qlen 1000
>>>> link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff
>>>> inet 192.168.0.11/24 scope global wan
>>>> valid_lft forever preferred_lft forever
>>>>
>>>> see no p5-TX/gmac-rx
>>
>>> Did you apply the vlan and flooding fix patches from Richard?
>>
>> have now applied all patches i've found from richard (which are all rejected):
>>
>> fe4495bb3cc2 2023-02-12 Fix setting up CPU and User ports to be in the correct
>> mode during setup and when toggling vlan_filtering on a bridge port. (HEAD ->
>> 6.3-rc)
>> b0641f3e1a69 2023-02-12 Fix Flooding: Disable by default on User ports and
>> Enable on CPU ports
>> cb04b3451524 2023-02-12 Do not add all User ports to the CPU by default. This
>> will break Multi CPU when added a seperate patch. It will be overwritten by
>> .port_enable and since we are forcing output to a port via the Special Tag
>> this is not needed.
>>
>> and now it seems working and is clear ;)
>>
>> root@bpi-r2:~# ip l show wan
>> 5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
>> mode DEFAULT group default qlen 1000
>> link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff
>>
>> iperf3
>> [ ID] Interval Transfer Bitrate Retr
>> [ 5] 0.00-10.00 sec 1.09 GBytes 940 Mbits/sec 0 sender
>> [ 5] 0.00-10.03 sec 1.09 GBytes 936 Mbits/sec receiver
>>
>>
>> iperf3 -R
>> [ ID] Interval Transfer Bitrate Retr
>> [ 5] 0.00-10.04 sec 1.09 GBytes 936 Mbits/sec 0 sender
>> [ 5] 0.00-10.00 sec 1.09 GBytes 938 Mbits/sec receiver
>>
>>
>> how do you deal with these patches? do you include them into your mt7530 fixes
>> series? they (and vladimirs preferred cpu-port) need to be applied before
>> these DTS-changes
>
> Dealing with this is the last step on my tasklist. Take a look:
>
> https://arinc9.notion.site/mt7530-c-improvements-bbfdc2ceb958484b9627297b88bc6d4a
>
I'm a bit lost here. @frank can this be merged now or are there still oustanding
issues. It seems to me that not, but just in case...
Regards,
Matthias
On 29.05.2023 16:40, Matthias Brugger wrote:
>
>
> On 12/04/2023 19:06, Arınç ÜNAL wrote:
>> On 12.04.2023 19:53, Frank Wunderlich wrote:
>>> Hi
>>>
>>>> Gesendet: Mittwoch, 12. April 2023 um 18:21 Uhr
>>>> Von: "Arınç ÜNAL" <[email protected]>
>>>>> thanks, it changes the master when i upgrade iproute to 6.1 (from
>>>>> debian bullseye-backports), but i cannot do any traffic on it after
>>>>> switching to gmac1...
>>>>>
>>>>> 5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
>>>>> noqueue state UP group default qlen 1000
>>>>> link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff
>>>>> inet 192.168.0.11/24 scope global wan
>>>>> valid_lft forever preferred_lft forever
>>>>>
>>>>> see no p5-TX/gmac-rx
>>>
>>>> Did you apply the vlan and flooding fix patches from Richard?
>>>
>>> have now applied all patches i've found from richard (which are all
>>> rejected):
>>>
>>> fe4495bb3cc2 2023-02-12 Fix setting up CPU and User ports to be in
>>> the correct mode during setup and when toggling vlan_filtering on a
>>> bridge port. (HEAD -> 6.3-rc)
>>> b0641f3e1a69 2023-02-12 Fix Flooding: Disable by default on User
>>> ports and Enable on CPU ports
>>> cb04b3451524 2023-02-12 Do not add all User ports to the CPU by
>>> default. This will break Multi CPU when added a seperate patch. It
>>> will be overwritten by .port_enable and since we are forcing output
>>> to a port via the Special Tag this is not needed.
>>>
>>> and now it seems working and is clear ;)
>>>
>>> root@bpi-r2:~# ip l show wan
>>> 5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
>>> state UP mode DEFAULT group default qlen 1000
>>> link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff
>>>
>>> iperf3
>>> [ ID] Interval Transfer Bitrate Retr
>>> [ 5] 0.00-10.00 sec 1.09 GBytes 940 Mbits/sec 0
>>> sender
>>> [ 5] 0.00-10.03 sec 1.09 GBytes 936 Mbits/sec
>>> receiver
>>>
>>>
>>> iperf3 -R
>>> [ ID] Interval Transfer Bitrate Retr
>>> [ 5] 0.00-10.04 sec 1.09 GBytes 936 Mbits/sec 0
>>> sender
>>> [ 5] 0.00-10.00 sec 1.09 GBytes 938 Mbits/sec
>>> receiver
>>>
>>>
>>> how do you deal with these patches? do you include them into your
>>> mt7530 fixes series? they (and vladimirs preferred cpu-port) need to
>>> be applied before these DTS-changes
>>
>> Dealing with this is the last step on my tasklist. Take a look:
>>
>> https://arinc9.notion.site/mt7530-c-improvements-bbfdc2ceb958484b9627297b88bc6d4a
>>
>
> I'm a bit lost here. @frank can this be merged now or are there still
> oustanding issues. It seems to me that not, but just in case...
I fixed the network connectivity issue on the MT7530 DSA sudriver which
was the main problem this patch series would cause. I don't see an issue
that should block this series anymore.
With the current MT7530 DSA sudriver, port 5 will be the active CPU port
instead of 6. I've got a patch series to prefer port 6 instead but in
the meantime, this patch series should be good to apply.
Arınç
On 03/06/2023 12:48, Arınç ÜNAL wrote:
> On 29.05.2023 16:40, Matthias Brugger wrote:
>>
>>
>> On 12/04/2023 19:06, Arınç ÜNAL wrote:
>>> On 12.04.2023 19:53, Frank Wunderlich wrote:
>>>> Hi
>>>>
>>>>> Gesendet: Mittwoch, 12. April 2023 um 18:21 Uhr
>>>>> Von: "Arınç ÜNAL" <[email protected]>
>>>>>> thanks, it changes the master when i upgrade iproute to 6.1 (from debian
>>>>>> bullseye-backports), but i cannot do any traffic on it after switching to
>>>>>> gmac1...
>>>>>>
>>>>>> 5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
>>>>>> state UP group default qlen 1000
>>>>>> link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff
>>>>>> inet 192.168.0.11/24 scope global wan
>>>>>> valid_lft forever preferred_lft forever
>>>>>>
>>>>>> see no p5-TX/gmac-rx
>>>>
>>>>> Did you apply the vlan and flooding fix patches from Richard?
>>>>
>>>> have now applied all patches i've found from richard (which are all rejected):
>>>>
>>>> fe4495bb3cc2 2023-02-12 Fix setting up CPU and User ports to be in the
>>>> correct mode during setup and when toggling vlan_filtering on a bridge
>>>> port. (HEAD -> 6.3-rc)
>>>> b0641f3e1a69 2023-02-12 Fix Flooding: Disable by default on User ports and
>>>> Enable on CPU ports
>>>> cb04b3451524 2023-02-12 Do not add all User ports to the CPU by default.
>>>> This will break Multi CPU when added a seperate patch. It will be
>>>> overwritten by .port_enable and since we are forcing output to a port via
>>>> the Special Tag this is not needed.
>>>>
>>>> and now it seems working and is clear ;)
>>>>
>>>> root@bpi-r2:~# ip l show wan
>>>> 5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
>>>> UP mode DEFAULT group default qlen 1000
>>>> link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff
>>>>
>>>> iperf3
>>>> [ ID] Interval Transfer Bitrate Retr
>>>> [ 5] 0.00-10.00 sec 1.09 GBytes 940 Mbits/sec 0 sender
>>>> [ 5] 0.00-10.03 sec 1.09 GBytes 936 Mbits/sec receiver
>>>>
>>>>
>>>> iperf3 -R
>>>> [ ID] Interval Transfer Bitrate Retr
>>>> [ 5] 0.00-10.04 sec 1.09 GBytes 936 Mbits/sec 0 sender
>>>> [ 5] 0.00-10.00 sec 1.09 GBytes 938 Mbits/sec receiver
>>>>
>>>>
>>>> how do you deal with these patches? do you include them into your mt7530
>>>> fixes series? they (and vladimirs preferred cpu-port) need to be applied
>>>> before these DTS-changes
>>>
>>> Dealing with this is the last step on my tasklist. Take a look:
>>>
>>> https://arinc9.notion.site/mt7530-c-improvements-bbfdc2ceb958484b9627297b88bc6d4a
>>>
>>
>> I'm a bit lost here. @frank can this be merged now or are there still
>> oustanding issues. It seems to me that not, but just in case...
>
> I fixed the network connectivity issue on the MT7530 DSA sudriver which was the
> main problem this patch series would cause. I don't see an issue that should
> block this series anymore.
>
> With the current MT7530 DSA sudriver, port 5 will be the active CPU port instead
> of 6. I've got a patch series to prefer port 6 instead but in the meantime, this
> patch series should be good to apply.
>
> Arınç
Applied now, thanks!