| Message ID | 20181214164847.4851-1-frank-w@public-files.de |
|---|---|
| Headers | show |
| Series | adding multiple CPU-Ports | expand |
Hi Frank, On 12/14/18 8:48 AM, Frank Wunderlich wrote: > some switch-chips have multiple CPU-Ports > > this patch-series adds basic functionality and handle the 2 > cpu-Ports of mt7530 on board BananaPi R2 > > changes to mtk-ethernet-driver are not included yet, > because here are still some issues with watchdog-timeouts > > most patches are based on OpenWRT-Patches created by > John Crispin and only ported to DSA-Core 4.15+ with 2 main differences: > - no change to platform-driver > - option in dts is named "default_cpu" instead of only "cpu" to > allow modification from userspace (additional patches needed) > > complete source (including eth-patches) is uploaded here: > https://github.com/frank-w/BPI-R2-4.14/commits/4.20-gmac-test Andrew, Vivien and I were discussing about multi-CPU support lately and we think that the best and most flexible way to allow multi-CPU ports to be supported is to allow enslaving the DSA master network devices (CPU Ethernet controllers) into a bridge because that will inherently define the mapping between ports. Enslaving the CPU port into the bridge is not currently allowed because processing of DSA switch tags and bridge frames were done in an incorrect order, but we can easily change that. So for instance in a dual CPU configuration interface with eth0 and eth1 being the two DSA master network devices and then lan1 through lan3 through lan4 being the user-visible LAN ports and wan being the wan pot, the set-up would look like this: ip link add dev br-lan type bridge ip link set dev lan1 master br-lan ... ip link set dev lan3 master br-lan ip link add dev br-wan typebridge ip link set dev wan master br-wan That way, if you ever wanted to have more/less ports on the LAN or WAN side, you could do that. The problem with the Device Tree approach is really that we are not sticking to a strict HW description, we are encoding a policy/user configuration in Device Tree. If that is acceptable to you, we can probably start working on some patches and have you help us test them? > > new in v2: > - added DTS-changes > - added cover-letter > - added change of dts-option (default_cpu) > > currently posted not to full maintainers-list for first review, > will do it when patches are ready :) > > Frank Wunderlich (8): > net: dsa: adding fields for holding information about upstream-port > net: dsa: add helper functions > net: dsa: adding handling of second CPU-Port > net: dsa: add support for GMAC2 wired to ext > net: dsa: dsa multi cpu (mt7530.c) > net: dsa: tell GDMA when we are turning on the special tag > net: dsa: mt7530 add linking to mdio > net: dsa: changes to dts > > arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 29 +++++++++- > drivers/net/dsa/mt7530.c | 55 +++++++++++++------ > drivers/net/dsa/mt7530.h | 4 ++ > include/net/dsa.h | 22 ++++++++ > net/dsa/dsa2.c | 36 ++++++++++++ > net/dsa/dsa_priv.h | 5 ++ > net/dsa/slave.c | 3 +- > 7 files changed, 135 insertions(+), 19 deletions(-) >
Hi, i can test it and of course help as far as i can... for the bridge-way this means that an unconfigured system does not have a connection between the user and the cpu-ports, right? If this is the desired way imho there should be a way to default a default, so that the device stays connectable if there is no user-config. Or is this you mean with "policy/user configuration in DT"? currently there is a bug in Ethernet-Patches you find on my github resulting in tx timeout (netdev watchdog) after switching connection (port1 down, reconnect cable to another port and bring this up) between interfaces. Thats the reason i only posted the dsa/dts-Part. I've contacted mediatek-Team (Ryder Lee, Marc-MC Lee, Landen Chao, Steven Liu) at beginning of this week and got a Patch from Ryder (you see on top of my repo) which unfortunately wont fix it. Maybe anyone here sees the Problem regards Frank > Gesendet: Freitag, 14. Dezember 2018 um 18:26 Uhr > Von: "Florian Fainelli" <f.fainelli@gmail.com> > An: "Frank Wunderlich" <frank-w@public-files.de>, "Matthias Brugger" <matthias.bgg@gmail.com>, netdev@vger.kernel.org, "Sean Wang" <sean.wang@mediatek.com>, "Andrew Lunn" <andrew@lunn.ch>, linux-mediatek@lists.infradead.org, vivien.didelot@gmail.com > Betreff: Re: [PATCH 0/8] adding multiple CPU-Ports > > Hi Frank, > > On 12/14/18 8:48 AM, Frank Wunderlich wrote: > > some switch-chips have multiple CPU-Ports > > > > this patch-series adds basic functionality and handle the 2 > > cpu-Ports of mt7530 on board BananaPi R2 > > > > changes to mtk-ethernet-driver are not included yet, > > because here are still some issues with watchdog-timeouts > > > > most patches are based on OpenWRT-Patches created by > > John Crispin and only ported to DSA-Core 4.15+ with 2 main differences: > > - no change to platform-driver > > - option in dts is named "default_cpu" instead of only "cpu" to > > allow modification from userspace (additional patches needed) > > > > complete source (including eth-patches) is uploaded here: > > https://github.com/frank-w/BPI-R2-4.14/commits/4.20-gmac-test > > Andrew, Vivien and I were discussing about multi-CPU support lately and > we think that the best and most flexible way to allow multi-CPU ports to > be supported is to allow enslaving the DSA master network devices (CPU > Ethernet controllers) into a bridge because that will inherently define > the mapping between ports. Enslaving the CPU port into the bridge is not > currently allowed because processing of DSA switch tags and bridge > frames were done in an incorrect order, but we can easily change that. > > So for instance in a dual CPU configuration interface with eth0 and eth1 > being the two DSA master network devices and then lan1 through lan3 > through lan4 being the user-visible LAN ports and wan being the wan pot, > the set-up would look like this: > > ip link add dev br-lan type bridge > ip link set dev lan1 master br-lan > ... > ip link set dev lan3 master br-lan > ip link add dev br-wan typebridge > ip link set dev wan master br-wan > > That way, if you ever wanted to have more/less ports on the LAN or WAN > side, you could do that. > > The problem with the Device Tree approach is really that we are not > sticking to a strict HW description, we are encoding a policy/user > configuration in Device Tree. > > If that is acceptable to you, we can probably start working on some > patches and have you help us test them? > > > > > new in v2: > > - added DTS-changes > > - added cover-letter > > - added change of dts-option (default_cpu) > > > > currently posted not to full maintainers-list for first review, > > will do it when patches are ready :) > > > > Frank Wunderlich (8): > > net: dsa: adding fields for holding information about upstream-port > > net: dsa: add helper functions > > net: dsa: adding handling of second CPU-Port > > net: dsa: add support for GMAC2 wired to ext > > net: dsa: dsa multi cpu (mt7530.c) > > net: dsa: tell GDMA when we are turning on the special tag > > net: dsa: mt7530 add linking to mdio > > net: dsa: changes to dts > > > > arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 29 +++++++++- > > drivers/net/dsa/mt7530.c | 55 +++++++++++++------ > > drivers/net/dsa/mt7530.h | 4 ++ > > include/net/dsa.h | 22 ++++++++ > > net/dsa/dsa2.c | 36 ++++++++++++ > > net/dsa/dsa_priv.h | 5 ++ > > net/dsa/slave.c | 3 +- > > 7 files changed, 135 insertions(+), 19 deletions(-) > > > > > -- > Florian >
On Fri, Dec 14, 2018 at 9:49 AM Frank Wunderlich <frank-w@public-files.de> wrote: > > Hi, > > i can test it and of course help as far as i can... > > for the bridge-way this means that an unconfigured system does not have a connection between the user and the cpu-ports, right? If this is the desired way imho there should be a way to default a default, so that the device stays connectable if there is no user-config. Or is this you mean with "policy/user configuration in DT"? > > currently there is a bug in Ethernet-Patches you find on my github resulting in tx timeout (netdev watchdog) after switching connection (port1 down, reconnect cable to another port and bring this up) between interfaces. Thats the reason i only posted the dsa/dts-Part. > > I've contacted mediatek-Team (Ryder Lee, Marc-MC Lee, Landen Chao, Steven Liu) at beginning of this week and got a Patch from Ryder (you see on top of my repo) which unfortunately wont fix it. Maybe anyone here sees the Problem > Is it a problem just present after applies those mulitple-cpus patches you propose here? or it also happens at the native code in mainline. > regards Frank > > > > Gesendet: Freitag, 14. Dezember 2018 um 18:26 Uhr > > Von: "Florian Fainelli" <f.fainelli@gmail.com> > > An: "Frank Wunderlich" <frank-w@public-files.de>, "Matthias Brugger" <matthias.bgg@gmail.com>, netdev@vger.kernel.org, "Sean Wang" <sean.wang@mediatek.com>, "Andrew Lunn" <andrew@lunn.ch>, linux-mediatek@lists.infradead.org, vivien.didelot@gmail.com > > Betreff: Re: [PATCH 0/8] adding multiple CPU-Ports > > > > Hi Frank, > > > > On 12/14/18 8:48 AM, Frank Wunderlich wrote: > > > some switch-chips have multiple CPU-Ports > > > > > > this patch-series adds basic functionality and handle the 2 > > > cpu-Ports of mt7530 on board BananaPi R2 > > > > > > changes to mtk-ethernet-driver are not included yet, > > > because here are still some issues with watchdog-timeouts > > > > > > most patches are based on OpenWRT-Patches created by > > > John Crispin and only ported to DSA-Core 4.15+ with 2 main differences: > > > - no change to platform-driver > > > - option in dts is named "default_cpu" instead of only "cpu" to > > > allow modification from userspace (additional patches needed) > > > > > > complete source (including eth-patches) is uploaded here: > > > https://github.com/frank-w/BPI-R2-4.14/commits/4.20-gmac-test > > > > Andrew, Vivien and I were discussing about multi-CPU support lately and > > we think that the best and most flexible way to allow multi-CPU ports to > > be supported is to allow enslaving the DSA master network devices (CPU > > Ethernet controllers) into a bridge because that will inherently define > > the mapping between ports. Enslaving the CPU port into the bridge is not > > currently allowed because processing of DSA switch tags and bridge > > frames were done in an incorrect order, but we can easily change that. > > > > So for instance in a dual CPU configuration interface with eth0 and eth1 > > being the two DSA master network devices and then lan1 through lan3 > > through lan4 being the user-visible LAN ports and wan being the wan pot, > > the set-up would look like this: > > > > ip link add dev br-lan type bridge > > ip link set dev lan1 master br-lan > > ... > > ip link set dev lan3 master br-lan > > ip link add dev br-wan typebridge > > ip link set dev wan master br-wan > > > > That way, if you ever wanted to have more/less ports on the LAN or WAN > > side, you could do that. > > > > The problem with the Device Tree approach is really that we are not > > sticking to a strict HW description, we are encoding a policy/user > > configuration in Device Tree. > > > > If that is acceptable to you, we can probably start working on some > > patches and have you help us test them? > > > > > > > > new in v2: > > > - added DTS-changes > > > - added cover-letter > > > - added change of dts-option (default_cpu) > > > > > > currently posted not to full maintainers-list for first review, > > > will do it when patches are ready :) > > > > > > Frank Wunderlich (8): > > > net: dsa: adding fields for holding information about upstream-port > > > net: dsa: add helper functions > > > net: dsa: adding handling of second CPU-Port > > > net: dsa: add support for GMAC2 wired to ext > > > net: dsa: dsa multi cpu (mt7530.c) > > > net: dsa: tell GDMA when we are turning on the special tag > > > net: dsa: mt7530 add linking to mdio > > > net: dsa: changes to dts > > > > > > arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 29 +++++++++- > > > drivers/net/dsa/mt7530.c | 55 +++++++++++++------ > > > drivers/net/dsa/mt7530.h | 4 ++ > > > include/net/dsa.h | 22 ++++++++ > > > net/dsa/dsa2.c | 36 ++++++++++++ > > > net/dsa/dsa_priv.h | 5 ++ > > > net/dsa/slave.c | 3 +- > > > 7 files changed, 135 insertions(+), 19 deletions(-) > > > > > > > > > -- > > Florian > > > > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
On 12/14/18 9:48 AM, Frank Wunderlich wrote: > Hi, > > i can test it and of course help as far as i can... > > for the bridge-way this means that an unconfigured system does not have a connection between the user and the cpu-ports, right? If this is the desired way imho there should be a way to default a default, so that the device stays connectable if there is no user-config. Or is this you mean with "policy/user configuration in DT"? Yes, this is what I mean with DT is dictating policy. If you have a properly working DSA switch driver, then all ports are segregated from one another and there is no cross talk, so there is no risk of e.g: exposing LAN devices to the WAN accidentally. > > currently there is a bug in Ethernet-Patches you find on my github resulting in tx timeout (netdev watchdog) after switching connection (port1 down, reconnect cable to another port and bring this up) between interfaces. Thats the reason i only posted the dsa/dts-Part. Strange, that sounds like a separate issue does not it? > > I've contacted mediatek-Team (Ryder Lee, Marc-MC Lee, Landen Chao, Steven Liu) at beginning of this week and got a Patch from Ryder (you see on top of my repo) which unfortunately wont fix it. Maybe anyone here sees the Problem Keep in mind that multi-CPU port is more of an optimization than a real necessity in most cases. If you have a single switch that spans multiple LAN/WAN ports and multiple CPU ports, the only advantage of assigning WAN to a specific CPU port and LAN ports to a specific CPU port is to effectively double the bandwidth, both within the switch and within the SoC's architecture (permitted it is designed that way). There is still, unless there is a NAT-P accelerator a need to perform IP routing in software... > > regards Frank > > >> Gesendet: Freitag, 14. Dezember 2018 um 18:26 Uhr >> Von: "Florian Fainelli" <f.fainelli@gmail.com> >> An: "Frank Wunderlich" <frank-w@public-files.de>, "Matthias Brugger" <matthias.bgg@gmail.com>, netdev@vger.kernel.org, "Sean Wang" <sean.wang@mediatek.com>, "Andrew Lunn" <andrew@lunn.ch>, linux-mediatek@lists.infradead.org, vivien.didelot@gmail.com >> Betreff: Re: [PATCH 0/8] adding multiple CPU-Ports >> >> Hi Frank, >> >> On 12/14/18 8:48 AM, Frank Wunderlich wrote: >>> some switch-chips have multiple CPU-Ports >>> >>> this patch-series adds basic functionality and handle the 2 >>> cpu-Ports of mt7530 on board BananaPi R2 >>> >>> changes to mtk-ethernet-driver are not included yet, >>> because here are still some issues with watchdog-timeouts >>> >>> most patches are based on OpenWRT-Patches created by >>> John Crispin and only ported to DSA-Core 4.15+ with 2 main differences: >>> - no change to platform-driver >>> - option in dts is named "default_cpu" instead of only "cpu" to >>> allow modification from userspace (additional patches needed) >>> >>> complete source (including eth-patches) is uploaded here: >>> https://github.com/frank-w/BPI-R2-4.14/commits/4.20-gmac-test >> >> Andrew, Vivien and I were discussing about multi-CPU support lately and >> we think that the best and most flexible way to allow multi-CPU ports to >> be supported is to allow enslaving the DSA master network devices (CPU >> Ethernet controllers) into a bridge because that will inherently define >> the mapping between ports. Enslaving the CPU port into the bridge is not >> currently allowed because processing of DSA switch tags and bridge >> frames were done in an incorrect order, but we can easily change that. >> >> So for instance in a dual CPU configuration interface with eth0 and eth1 >> being the two DSA master network devices and then lan1 through lan3 >> through lan4 being the user-visible LAN ports and wan being the wan pot, >> the set-up would look like this: >> >> ip link add dev br-lan type bridge >> ip link set dev lan1 master br-lan >> ... >> ip link set dev lan3 master br-lan >> ip link add dev br-wan typebridge >> ip link set dev wan master br-wan >> >> That way, if you ever wanted to have more/less ports on the LAN or WAN >> side, you could do that. >> >> The problem with the Device Tree approach is really that we are not >> sticking to a strict HW description, we are encoding a policy/user >> configuration in Device Tree. >> >> If that is acceptable to you, we can probably start working on some >> patches and have you help us test them? >> >>> >>> new in v2: >>> - added DTS-changes >>> - added cover-letter >>> - added change of dts-option (default_cpu) >>> >>> currently posted not to full maintainers-list for first review, >>> will do it when patches are ready :) >>> >>> Frank Wunderlich (8): >>> net: dsa: adding fields for holding information about upstream-port >>> net: dsa: add helper functions >>> net: dsa: adding handling of second CPU-Port >>> net: dsa: add support for GMAC2 wired to ext >>> net: dsa: dsa multi cpu (mt7530.c) >>> net: dsa: tell GDMA when we are turning on the special tag >>> net: dsa: mt7530 add linking to mdio >>> net: dsa: changes to dts >>> >>> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 29 +++++++++- >>> drivers/net/dsa/mt7530.c | 55 +++++++++++++------ >>> drivers/net/dsa/mt7530.h | 4 ++ >>> include/net/dsa.h | 22 ++++++++ >>> net/dsa/dsa2.c | 36 ++++++++++++ >>> net/dsa/dsa_priv.h | 5 ++ >>> net/dsa/slave.c | 3 +- >>> 7 files changed, 135 insertions(+), 19 deletions(-) >>> >> >> >> -- >> Florian >>
Hi, > Von: "Florian Fainelli" <f.fainelli@gmail.com> > > Yes, this is what I mean with DT is dictating policy. If you have a > properly working DSA switch driver, then all ports are segregated from > one another and there is no cross talk, so there is no risk of e.g: > exposing LAN devices to the WAN accidentally. how can i test this with single CPU-Port? this is one intention to get second cpu-port working. > > currently there is a bug in Ethernet-Patches you find on my github resulting in tx timeout (netdev watchdog) after switching connection (port1 down, reconnect cable to another port and bring this up) between interfaces. Thats the reason i only posted the dsa/dts-Part. > > Strange, that sounds like a separate issue does not it? i expect this issue is not in this Patch-Series, but i want to be honest that i not fixed the issue i've found while testing. but the dsa-mapping seems correct and i've seen no packetloss while testing over eth0 and eth1 (Ping with 1000+ packets and "normal" traffic), only with iperf. here are many people which may help me to get it solved and i don't expect that my patch-series will me merged to mainline in the current state. It is just to get feedback to (my) current way, but of course i want to get it working in mainline anyhow :) i don't want to steal anybodys time, but in this specific part i need some help. I've spend much time to get Johns Patches working so far in 4.20. after googling around (and writing with andrew and ryder) the problem seems to be in interrupt-handling of second port or in this patch (which seems to be needed as far as i understand johns Patches): https://github.com/frank-w/BPI-R2-4.14/commit/150fa665aa1d482a8360d2ad00271f62da3a9b05 ("add BQL-related changes"). this issue seems to be only triggered if i make much traffic (iperf) and switching the testing port multiple times (wan=>lan=>wan). > Von: "Sean Wang" <sean.wang@kernel.org> > Is it a problem just present after applies those mulitple-cpus patches > you propose here? or it also happens at the native code in mainline. as i wrote here above i guess the problem is not in dsa-code i've posted (but i cannot be sure so i've added the hint)....more in BQL/DMA-handling of ethernet-driver, but i currently not know if it's in mainline-driver or after my patches. I do not full understand the interrupt-/packet-handling in driver...i've only ported Johns Patches to the new (dsa-) Framework. Imho i cannot test with this dsa-patches alone, because it seems that modifications of ethernet-driver is also necessary...correct me please if i'm wrong. i've tested same in 4.14 with johns Patches (https://github.com/frank-w/BPI-R2-4.14/tree/4.14-main/) and cannot trigger this issue there. btw. your email-account is still bouncing (@sean). > > I've contacted mediatek-Team (Ryder Lee, Marc-MC Lee, Landen Chao, Steven Liu) at beginning of this week and got a Patch from Ryder (you see on top of my repo) which unfortunately wont fix it. Maybe anyone here sees the Problem > > Keep in mind that multi-CPU port is more of an optimization than a real > necessity in most cases. If you have a single switch that spans multiple > LAN/WAN ports and multiple CPU ports, the only advantage of assigning > WAN to a specific CPU port and LAN ports to a specific CPU port is to > effectively double the bandwidth, both within the switch and within the > SoC's architecture (permitted it is designed that way). There is still, > unless there is a NAT-P accelerator a need to perform IP routing in > software... right, imho if i make a software-bridge over dsa-user-ports (e.g. bridging lan0-lan3) the traffic from one lan-port goes to the SOC and back over 1 CPU-Lane, so if these lan-Ports are each 1 GBit (and there is nearly the maximum traffic) and CPU-Lane has 2GBit full-duplex (TRGMII) boost, 2 Ports are enough to make the CPU-Lane "close" and no additional Traffic is left for the other 3 Ports (wan + 2 x lan). Thats my main motivation getting the second lane working. regards Frank
Hi,
have tested only my dsa-Patches (no ethernet-changes), and what should i say...it seems to work well. second gmac is recognized, i can have traffic on both and iperf works...without any crash (tried 5 port changes with iperf between).
root@bpi-r2:~# ip a
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 0a:83:39:52:bd:d3 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 92:97:25:d5:ee:2e brd ff:ff:ff:ff:ff:ff
4: wan@eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 92:97:25:d5:ee:2e brd ff:ff:ff:ff:ff:ff
inet 192.168.0.11/24 brd 192.168.0.255 scope global wan
valid_lft forever preferred_lft forever
5: lan0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 0a:83:39:52:bd:d3 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.19/24 scope global lan0
valid_lft forever preferred_lft forever
6: lan1@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 0a:83:39:52:bd:d3 brd ff:ff:ff:ff:ff:ff
7: lan2@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 0a:83:39:52:bd:d3 brd ff:ff:ff:ff:ff:ff
8: lan3@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 0a:83:39:52:bd:d3 brd ff:ff:ff:ff:ff:ff
root@bpi-r2:~# iperf -c 192.168.0.21
------------------------------------------------------------
Client connecting to 192.168.0.21, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.19 port 50214 connected with 192.168.0.21 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.10 GBytes 942 Mbits/sec
root@bpi-r2:~# ip link set lan0 down
[ 2315.268071] mt7530 mdio-bus:00 lan0: Link is Down
root@bpi-r2:~# ip link set wan up
[ 2320.668174] mt7530 mdio-bus:00 wan: configuring for phy/gmii link mode
root@bpi-r2:~# [ 2326.952615] mt7530 mdio-bus:00 wan: Link is Up - 1Gbps/Full - flow control off
root@bpi-r2:~# iperf -c 192.168.0.21
------------------------------------------------------------
Client connecting to 192.168.0.21, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.11 port 35702 connected with 192.168.0.21 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.09 GBytes 940 Mbits/sec
root@bpi-r2:~# ip link set wan down
[ 2454.117736] mt7530 mdio-bus:00 wan: Link is Down
root@bpi-r2:~# ip link set lan0 up
[ 2458.038099] mt7530 mdio-bus:00 lan0: configuring for phy/gmii link mode
root@bpi-r2:~#
root@bpi-r2:~# [ 2465.352619] mt7530 mdio-bus:00 lan0: Link is Up - 1Gbps/Full - flow control off
root@bpi-r2:~# iperf -c 192.168.0.21
------------------------------------------------------------
Client connecting to 192.168.0.21, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.19 port 50218 connected with 192.168.0.21 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.10 GBytes 942 Mbits/sec
...
root@bpi-r2:~# uname -r
4.20.0-rc1-bpi-r2-gmac_test_dsa_only
https://github.com/frank-w/BPI-R2-4.14/tree/4.20-gmac_test_dsa_only
i make some additional tests, but it looks well now :)
regards Frank
some switch-chips have multiple CPU-Ports this patch-series adds basic functionality and handle the 2 cpu-Ports of mt7530 on board BananaPi R2 changes to mtk-ethernet-driver are not included yet, because here are still some issues with watchdog-timeouts most patches are based on OpenWRT-Patches created by John Crispin and only ported to DSA-Core 4.15+ with 2 main differences: - no change to platform-driver - option in dts is named "default_cpu" instead of only "cpu" to allow modification from userspace (additional patches needed) complete source (including eth-patches) is uploaded here: https://github.com/frank-w/BPI-R2-4.14/commits/4.20-gmac-test new in v2: - added DTS-changes - added cover-letter - added change of dts-option (default_cpu) currently posted not to full maintainers-list for first review, will do it when patches are ready :) Frank Wunderlich (8): net: dsa: adding fields for holding information about upstream-port net: dsa: add helper functions net: dsa: adding handling of second CPU-Port net: dsa: add support for GMAC2 wired to ext net: dsa: dsa multi cpu (mt7530.c) net: dsa: tell GDMA when we are turning on the special tag net: dsa: mt7530 add linking to mdio net: dsa: changes to dts arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 29 +++++++++- drivers/net/dsa/mt7530.c | 55 +++++++++++++------ drivers/net/dsa/mt7530.h | 4 ++ include/net/dsa.h | 22 ++++++++ net/dsa/dsa2.c | 36 ++++++++++++ net/dsa/dsa_priv.h | 5 ++ net/dsa/slave.c | 3 +- 7 files changed, 135 insertions(+), 19 deletions(-)