[OpenWrt-Devel,v2] gemini: Bring up DSA switches
diff mbox series

Message ID 20190714135037.18471-1-linus.walleij@linaro.org
State New
Headers show
Series
  • [OpenWrt-Devel,v2] gemini: Bring up DSA switches
Related show

Commit Message

Linus Walleij July 14, 2019, 1:50 p.m. UTC
First group the interfaces on the DSA switch into the
right LAN/WAN groups. Tested successfully on the Itian
Square One SQ201 and the SL93512 reference design
with the Vitesse DSA switches.

As discussed on the mailing list, these switches are
untagged (DSA_TAG_PROTO_NONE) so the DSA slave devices
are only slave devices with not datapath control.
This means each of the CPU-facing interfaces need to
be brought up with the "none" protocol before any
slave devices are brought up. (The sequence matters
here.)

Tested on each of the three affected devices.

Cc: Pawel Dembicki <paweldembicki@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Remove the eth1 from the LAN bridge in both the
  Vitesse switch devices, instead bring up each ethernet
  master interface independently with "none" protocol.
---
 .../gemini/base-files/etc/board.d/02_network  | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100755 target/linux/gemini/base-files/etc/board.d/02_network

Comments

Paweł Dembicki July 14, 2019, 3:15 p.m. UTC | #1
On 14.07.2019 15:50, Linus Walleij wrote:

> +storlink,gemini324)
> +	# These are all connected to eth1 thru VSC7385
> +	ucidef_set_interface "eth" ifname "eth1" protocol "none"
> +	ucidef_set_interfaces_lan_wan "eth1 lan1 lan2 lan3 lan4" "eth0"
> +	;;

and:

> +itian,sq201)
> +	# These are all connected to eth1 thru VSC7395
> +	ucidef_set_interface "eth" ifname "eth1" protocol "none"
> +	ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" "eth0"
> +	;;

Hi Linus,

I can't reproduce working state on P2020RDB with this two methods.
In my device work this sequence:

ip link set eth0 up
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up
ip link set lan4 up
ip link add name br-lan type bridge
ip link set dev lan1 master br-lan
ip link set dev lan2 master br-lan
ip link set dev lan3 master br-lan
ip link set dev lan4 master br-lan
ip addr add 192.168.1.1/24 dev br-lan
ip link set dev br-lan up
ip link set dev eth0 master br-lan

I think, vsc73xx without vlan filtering is very tricky now.

Best Regards,
Pawel Dembicki
Linus Walleij July 14, 2019, 8:46 p.m. UTC | #2
On Sun, Jul 14, 2019 at 5:15 PM Pawel Dembicki <paweldembicki@gmail.com> wrote:

> > +storlink,gemini324)
> > +     # These are all connected to eth1 thru VSC7385
> > +     ucidef_set_interface "eth" ifname "eth1" protocol "none"
> > +     ucidef_set_interfaces_lan_wan "eth1 lan1 lan2 lan3 lan4" "eth0"
> > +     ;;

Ooops I say I shall fix it then I don't. eth1 is still there.

OK I fix a v3. The switch is working fine on the VSC7385 like
this.

> I can't reproduce working state on P2020RDB with this two methods.
> In my device work this sequence:
>
> ip link set eth0 up
> ip link set lan1 up
> ip link set lan2 up
> ip link set lan3 up
> ip link set lan4 up
> ip link add name br-lan type bridge
> ip link set dev lan1 master br-lan
> ip link set dev lan2 master br-lan
> ip link set dev lan3 master br-lan
> ip link set dev lan4 master br-lan
> ip addr add 192.168.1.1/24 dev br-lan
> ip link set dev br-lan up
> ip link set dev eth0 master br-lan
>
> I think, vsc73xx without vlan filtering is very tricky now.

I think you should have it like this:

ucidef_set_interface "eth" ifname "eth0" protocol "none"
ucidef_set_interfaces_lan "lan1 lan2 lan3 lan4"

If you don't have any WAN interface (uplink) on the device.

Yours,
Linus Walleij
Linus Walleij July 14, 2019, 9:11 p.m. UTC | #3
On Sun, Jul 14, 2019 at 10:46 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Sun, Jul 14, 2019 at 5:15 PM Pawel Dembicki <paweldembicki@gmail.com> wrote:
>
> > > +storlink,gemini324)
> > > +     # These are all connected to eth1 thru VSC7385
> > > +     ucidef_set_interface "eth" ifname "eth1" protocol "none"
> > > +     ucidef_set_interfaces_lan_wan "eth1 lan1 lan2 lan3 lan4" "eth0"
> > > +     ;;
>
> Ooops I say I shall fix it then I don't. eth1 is still there.
>
> OK I fix a v3. The switch is working fine on the VSC7385 like
> this.

Or no it doesn't. I'm not smart today...
Keeping eth1 as "none" isn't working. I had to assign
a static address (the same) to eth1 as well, then it works.

In /etc/config/network it looks like this:

config interface 'eth'
        option ifname 'eth1'
        option proto 'static'
        option ipaddr '169.254.1.2'
        option netmask '255.255.255.0'

config interface 'lan'
        option type 'bridge'
        option ifname 'lan1 lan2 lan3 lan4'
        option proto 'static'
        option ipaddr '169.254.1.2'
        option netmask '255.255.255.0'
        option ip6assign '60'

I don't know if there is any better way to fix it?

Yours,
Linus Walleij
Paweł Dembicki July 19, 2019, 4:49 a.m. UTC | #4
On Sun, Jul 14, 2019 at 23:12 Linus Walleij <linus.walleij@linaro.org> wrote:
>
>
> I don't know if there is any better way to fix it?
>

I think, that the best approach is vlan filtering. I started some work:
https://github.com/CHKDSK88/linux/commit/38b62482d9f828b5720db11145fa474e368b248c

At this moment it works (I used ip-full and ip-bridge packets). But I
have no idea how to integrate dsa vlan filtering with OpenWRT
configuration.
This is first dsa switch with DSA_TAG_PROTO_NONE in OpenWRT.

Best regards,
Pawel Dembicki
Linus Walleij July 19, 2019, 7:50 a.m. UTC | #5
On Fri, Jul 19, 2019 at 6:49 AM Paweł Dembicki <paweldembicki@gmail.com> wrote:

> I think, that the best approach is vlan filtering. I started some work:
> https://github.com/CHKDSK88/linux/commit/38b62482d9f828b5720db11145fa474e368b248c

Hey! I wanted to do that but never had time,
 so very happy that you're fixing it up! :)

> At this moment it works (I used ip-full and ip-bridge packets). But I
> have no idea how to integrate dsa vlan filtering with OpenWRT
> configuration.
> This is first dsa switch with DSA_TAG_PROTO_NONE in OpenWRT.

I think in the upstream kernel look at
commit f9bbe4477c30ece44296437ee26142b42ef8070b
"net: dsa: Optional VLAN-based port separation for switches without tagging"
by Vladimir Oltean.

I intuitively think this is what we want to do in the end is use
DSA_TAG_PROTO_8021Q but admittedly I don't think I
understand VLANs well enough for enabling this.

For OpenWrt using kernel v4.19 I have no idea what the best would
be. I don't think Vladimir's work can be easily backported.
I suppose some special hack to just bring up the DSA with
a custom script is the best compromise for the time being.

FYI this board supported by OpenWrt also has this switch:
https://openwrt.org/toh/evaluation.boards/pb44
with a custom driver:
https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/files/drivers/spi/spi-vsc7385.c
It's a MIPS device though, and I don't know if anyone is
actively maintaining it and could test to migrate it to this
new driver and help out?

Yours,
Linus Walleij
Paweł Dembicki July 19, 2019, 9:22 a.m. UTC | #6
> On Fri, Jul 19, 2019 at 09:51 Linus Walleij <linus.walleij@linaro.org> wrote:
>
> > I think, that the best approach is vlan filtering. I started some work:
> > https://github.com/CHKDSK88/linux/commit/38b62482d9f828b5720db11145fa474e368b248c
>
> Hey! I wanted to do that but never had time,
>  so very happy that you're fixing it up! :)
>

It would be great if You found some time to test it. :)

> > At this moment it works (I used ip-full and ip-bridge packets). But I
> > have no idea how to integrate dsa vlan filtering with OpenWRT
> > configuration.
> > This is first dsa switch with DSA_TAG_PROTO_NONE in OpenWRT.
>
> I think in the upstream kernel look at
> commit f9bbe4477c30ece44296437ee26142b42ef8070b
> "net: dsa: Optional VLAN-based port separation for switches without tagging"
> by Vladimir Oltean.
>
> I intuitively think this is what we want to do in the end is use
> DSA_TAG_PROTO_8021Q but admittedly I don't think I
> understand VLANs well enough for enabling this.
>

This is the question for OpenWRT core developers. What is the best
approach for DSA_TAG_PROTO_NONE switches?

DSA_TAG_PROTO_8021Q or just vlan filtering and configuration without
tagging support? Both solutions can give You port separation.

Personally I prefer simple vlan separation. This method was used in
OpenWRT for many non-dsa switches. But it need to create API for dsa
devices.

> For OpenWrt using kernel v4.19 I have no idea what the best would
> be. I don't think Vladimir's work can be easily backported.
> I suppose some special hack to just bring up the DSA with
> a custom script is the best compromise for the time being.
>

I agree with You. At this moment only hack could work.


> FYI this board supported by OpenWrt also has this switch:
> https://openwrt.org/toh/evaluation.boards/pb44
> with a custom driver:
> https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/files/drivers/spi/spi-vsc7385.c
> It's a MIPS device though, and I don't know if anyone is
> actively maintaining it and could test to migrate it to this
> new driver and help out?

Pb44 isn't ported to ath79 yet. I think, it is abandoned at this moment.

Best Regards,
Pawel Dembicki
Vladimir Oltean July 19, 2019, 11:59 a.m. UTC | #7
Hi Pawel, Linus,

On Fri, 19 Jul 2019 at 12:22, Paweł Dembicki <paweldembicki@gmail.com> wrote:
>
> > On Fri, Jul 19, 2019 at 09:51 Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > > I think, that the best approach is vlan filtering. I started some work:
> > > https://github.com/CHKDSK88/linux/commit/38b62482d9f828b5720db11145fa474e368b248c
> >
> > Hey! I wanted to do that but never had time,
> >  so very happy that you're fixing it up! :)
> >
>
> It would be great if You found some time to test it. :)
>
> > > At this moment it works (I used ip-full and ip-bridge packets). But I
> > > have no idea how to integrate dsa vlan filtering with OpenWRT
> > > configuration.
> > > This is first dsa switch with DSA_TAG_PROTO_NONE in OpenWRT.
> >
> > I think in the upstream kernel look at
> > commit f9bbe4477c30ece44296437ee26142b42ef8070b
> > "net: dsa: Optional VLAN-based port separation for switches without tagging"
> > by Vladimir Oltean.
> >
> > I intuitively think this is what we want to do in the end is use
> > DSA_TAG_PROTO_8021Q but admittedly I don't think I
> > understand VLANs well enough for enabling this.
> >
>
> This is the question for OpenWRT core developers. What is the best
> approach for DSA_TAG_PROTO_NONE switches?
>
> DSA_TAG_PROTO_8021Q or just vlan filtering and configuration without
> tagging support? Both solutions can give You port separation.
>
> Personally I prefer simple vlan separation. This method was used in
> OpenWRT for many non-dsa switches. But it need to create API for dsa
> devices.
>

I have never used OpenWRT on a board having an L2 switch so I don't
know how traffic over the switch ports is managed there.
In theory it is possible to transplant the
dsa_port_setup_8021q_tagging function from net/dsa/tag_8021q.c into a
shell script that operates with 'bridge vlan' operations.
However you will quickly find that you will need to do 'bridge vlan
add vid ${rx_vid} dev ${cpu_port}' aka "tagged egress" <- but
surprise, there is no CPU port net device exposed to userspace. I see
you overcame this by hardcoding the CPU port as a VLAN trunk for all
VLANs added on the user ports. This is going to work as a hack, but
you will need to add 2 VLAN sub-interfaces to the master port per
switch front-panel port - one for TX and another for RX. Otherwise you
will have the switch work as standalone net devices, but you'll break
its core functionality - switching. And you'll likely need to do
exotic things with applications that need bidirectional communication
over switch ports, because ingress and egress will happen over
different interfaces.
DSA_TAG_PROTO_8021Q abstracts all of that away and the switch
netdevices will not need any VLAN sub-interface on top of the master
port, and no hardcoding of VLAN trunking over the CPU port either.
But then there's the semantics issue - the network stack expects that
a bridge with vlan_filtering disabled (the default) passes frames with
the 802.1Q EtherType (0x8100) unmodified. It also expects that the
switch doesn't perform port membership enforcements based on the VLAN
ID. To be compliant, you'll either need to go your route and install
the VLANs from userspace (hence you activate vlan_filtering which will
means that having a bridge will be a requirement, even the "standalone
ports" mode will be emulated), and accept the above limitations, or go
with DSA_TAG_PROTO_8021Q and figure out a way that the switch parses
and emits VLAN-tagged frames using a different EtherType than the
default (case in which the stack will not need to know that the switch
is dealing with VLANs as part of its tagging protocol). And when
vlan_filtering is enabled, you either have to expose the VLANs used
for tagging to the bridge core, or encapsulate the custom tags, or
disable tagging. If you choose DSA_TAG_PROTO_8021Q, there is no
universal way to ensure the switch treats standard 802.1Q frames
distinctly from custom 802.1Q ones - whatever works and is supported
by your hardware.
Again, with a network stack framework that doesn't rely on the bridge
driver (I don't know how OpenWRT/swconfig works), the requirement that
the switch obeys the vlan_filtering semantics may be much more lax.
For DSA/switchdev, it is what it is.
You should also consider that you need Shared VLAN Learning (instead
of Independent VLAN Learning) in order not to break address learning
and have the switch flood everything.

> > For OpenWrt using kernel v4.19 I have no idea what the best would
> > be. I don't think Vladimir's work can be easily backported.
> > I suppose some special hack to just bring up the DSA with
> > a custom script is the best compromise for the time being.
> >
>
> I agree with You. At this moment only hack could work.
>
>
> > FYI this board supported by OpenWrt also has this switch:
> > https://openwrt.org/toh/evaluation.boards/pb44
> > with a custom driver:
> > https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/files/drivers/spi/spi-vsc7385.c
> > It's a MIPS device though, and I don't know if anyone is
> > actively maintaining it and could test to migrate it to this
> > new driver and help out?
>
> Pb44 isn't ported to ath79 yet. I think, it is abandoned at this moment.
>
> Best Regards,
> Pawel Dembicki

Hope this helps,
-Vladimir

Patch
diff mbox series

diff --git a/target/linux/gemini/base-files/etc/board.d/02_network b/target/linux/gemini/base-files/etc/board.d/02_network
new file mode 100755
index 000000000000..b5c486666c82
--- /dev/null
+++ b/target/linux/gemini/base-files/etc/board.d/02_network
@@ -0,0 +1,27 @@ 
+#!/bin/sh
+
+. /lib/functions/uci-defaults.sh
+
+board_config_update
+
+case "$(board_name)" in
+storlink,gemini324)
+	# These are all connected to eth1 thru VSC7385
+	ucidef_set_interface "eth" ifname "eth1" protocol "none"
+	ucidef_set_interfaces_lan_wan "eth1 lan1 lan2 lan3 lan4" "eth0"
+	;;
+itian,sq201)
+	# These are all connected to eth1 thru VSC7395
+	ucidef_set_interface "eth" ifname "eth1" protocol "none"
+	ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" "eth0"
+	;;
+dlink,dir-685)
+	# These are all connected to eth0 thru RTL8366RB
+	ucidef_set_interface "eth" ifname "eth0" protocol "none"
+	ucidef_set_interfaces_lan_wan "lan0 lan1 lan2 lan3" "wan"
+	;;
+esac
+
+board_config_flush
+
+exit 0