Message-ID: <0d78bf87-8f91-6936-6366-5900f9070383@gmail.com>
Date:   Fri, 14 Dec 2018 12:35:40 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Frank Wunderlich <frank-w@...lic-files.de>
Cc:     Matthias Brugger <matthias.bgg@...il.com>, netdev@...r.kernel.org,
        Sean Wang <sean.wang@...iatek.com>,
        Andrew Lunn <andrew@...n.ch>,
        linux-mediatek@...ts.infradead.org, vivien.didelot@...il.com
Subject: Re: Aw: Re: [PATCH 0/8] adding multiple CPU-Ports

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@...il.com>
>> An: "Frank Wunderlich" <frank-w@...lic-files.de>, "Matthias Brugger" <matthias.bgg@...il.com>, netdev@...r.kernel.org, "Sean Wang" <sean.wang@...iatek.com>, "Andrew Lunn" <andrew@...n.ch>, linux-mediatek@...ts.infradead.org, vivien.didelot@...il.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
>>


-- 
Florian

Powered by blists - more mailing lists