mbox series

[0/8] adding multiple CPU-Ports

Message ID 20181214164847.4851-1-frank-w@public-files.de (mailing list archive)
Headers show
Series adding multiple CPU-Ports | expand

Message

Frank Wunderlich Dec. 14, 2018, 4:48 p.m. UTC
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(-)

Comments

Florian Fainelli Dec. 14, 2018, 5:26 p.m. UTC | #1
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(-)
>
Frank Wunderlich Dec. 14, 2018, 5:48 p.m. UTC | #2
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
>
Sean Wang Dec. 14, 2018, 8:31 p.m. UTC | #3
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
Florian Fainelli Dec. 14, 2018, 8:35 p.m. UTC | #4
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
>>
Frank Wunderlich Dec. 15, 2018, 10:01 a.m. UTC | #5
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
Frank Wunderlich Dec. 15, 2018, 5:43 p.m. UTC | #6
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