All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] net: dsa: fix mv88e6xxx switches
@ 2016-01-23 10:51 Russell King
  2016-01-23 18:15 ` Andrew Lunn
  0 siblings, 1 reply; 11+ messages in thread
From: Russell King @ 2016-01-23 10:51 UTC (permalink / raw)
  To: Vivien Didelot, Andrew Lunn; +Cc: netdev

Since commit 76e398a62712 ("net: dsa: use switchdev obj for VLAN add/del
ops"), the Marvell 88E6xxx switch has been unable to pass traffic
between ports - any received traffic is discarded by the switch.
Taking a port out of bridge mode and configuring a vlan on it also the
port to start passing traffic.

With the debugfs files re-instated to allow debug of this issue by
comparing the register settings between the working and non-working
case, the reason becomes clear:

     GLOBAL GLOBAL2 SERDES   0    1    2    3    4    5    6
- 7:  1111    707f    2001     2    2    2    2    2    0    2
+ 7:  1111    707f    2001     1    1    1    1    1    0    1

Register 7 for the ports is the default vlan tag register, and in the
non-working setup, it has been set to 2, despite vlan 2 not being
configured.  This causes the switch to drop all packets coming in to
these ports.  The working setup has the default vlan tag register set
to 1, which is the default vlan when none is configured.

Inspection of the code reveals why.  The code prior to this commit
was:

-		for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {
...
-			if (!err && vlan->flags & BRIDGE_VLAN_INFO_PVID)
-				err = ds->drv->port_pvid_set(ds, p->port, vid);

but the new code is:

+	for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {
...
+	}
...
+	if (pvid)
+		err = _mv88e6xxx_port_pvid_set(ds, port, vid);

This causes the new code to always set the default vlan to one higher
than the old code.

Fix this.

Fixes: 76e398a62712 ("net: dsa: use switchdev obj for VLAN add/del ops")
Cc: <stable@vger.kernel.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
As this is a regression on 4.4 compared to 4.3, I've added the stable
tag.

 drivers/net/dsa/mv88e6xxx.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index b06dba05594a..bf622675397d 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -1515,11 +1515,12 @@ int mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port,
 		err = _mv88e6xxx_port_vlan_add(ds, port, vid, untagged);
 		if (err)
 			goto unlock;
+
+		/* no PVID with ranges, otherwise it's a bug */
+		if (pvid)
+			err = _mv88e6xxx_port_pvid_set(ds, port, vid);
 	}
 
-	/* no PVID with ranges, otherwise it's a bug */
-	if (pvid)
-		err = _mv88e6xxx_port_pvid_set(ds, port, vid);
 unlock:
 	mutex_unlock(&ps->smi_mutex);
 
-- 
2.1.0

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCH] net: dsa: fix mv88e6xxx switches
  2016-01-23 10:51 [PATCH] net: dsa: fix mv88e6xxx switches Russell King
@ 2016-01-23 18:15 ` Andrew Lunn
  2016-01-23 19:06   ` Russell King - ARM Linux
  0 siblings, 1 reply; 11+ messages in thread
From: Andrew Lunn @ 2016-01-23 18:15 UTC (permalink / raw)
  To: Russell King; +Cc: Vivien Didelot, netdev

On Sat, Jan 23, 2016 at 10:51:16AM +0000, Russell King wrote:
> Since commit 76e398a62712 ("net: dsa: use switchdev obj for VLAN add/del
> ops"), the Marvell 88E6xxx switch has been unable to pass traffic
> between ports - any received traffic is discarded by the switch.
> Taking a port out of bridge mode and configuring a vlan on it also the
> port to start passing traffic.
> 
> With the debugfs files re-instated to allow debug of this issue by
> comparing the register settings between the working and non-working
> case, the reason becomes clear:
> 
>      GLOBAL GLOBAL2 SERDES   0    1    2    3    4    5    6
> - 7:  1111    707f    2001     2    2    2    2    2    0    2
> + 7:  1111    707f    2001     1    1    1    1    1    0    1
> 
> Register 7 for the ports is the default vlan tag register, and in the
> non-working setup, it has been set to 2, despite vlan 2 not being
> configured.  This causes the switch to drop all packets coming in to
> these ports.  The working setup has the default vlan tag register set
> to 1, which is the default vlan when none is configured.
> 
> Inspection of the code reveals why.  The code prior to this commit
> was:
> 
> -		for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {
> ...
> -			if (!err && vlan->flags & BRIDGE_VLAN_INFO_PVID)
> -				err = ds->drv->port_pvid_set(ds, p->port, vid);
> 
> but the new code is:
> 
> +	for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {
> ...
> +	}
> ...
> +	if (pvid)
> +		err = _mv88e6xxx_port_pvid_set(ds, port, vid);
> 
> This causes the new code to always set the default vlan to one higher
> than the old code.
> 
> Fix this.
> 
> Fixes: 76e398a62712 ("net: dsa: use switchdev obj for VLAN add/del ops")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Hi Russell

Thanks for digging into this.

I think this is a step towards a solution, but does not solve all the
problems.

e.g. I have a switch interface lan0 with the IP address
192.168.10.2. I can ping this address from another host. I then take
the IP address off the interface, create a br0 device, add lan0 to the
bridge, and put 192.168.10.2 onto the bridge. I should be able to then
ping the address. But it does not work.

     Andrew

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] net: dsa: fix mv88e6xxx switches
  2016-01-23 18:15 ` Andrew Lunn
@ 2016-01-23 19:06   ` Russell King - ARM Linux
  2016-01-23 19:37     ` Andrew Lunn
  0 siblings, 1 reply; 11+ messages in thread
From: Russell King - ARM Linux @ 2016-01-23 19:06 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: Vivien Didelot, netdev

On Sat, Jan 23, 2016 at 07:15:26PM +0100, Andrew Lunn wrote:
> Thanks for digging into this.

I hope you saw v2, which is functionally identical.

> I think this is a step towards a solution, but does not solve all the
> problems.
> 
> e.g. I have a switch interface lan0 with the IP address
> 192.168.10.2. I can ping this address from another host. I then take
> the IP address off the interface, create a br0 device, add lan0 to the
> bridge, and put 192.168.10.2 onto the bridge. I should be able to then
> ping the address. But it does not work.

That works for me.  Maybe it's differences in the switch device?  I
seem to remember you said your switch was an older generation than
mine (88E6176).

root@clearfog:~# brctl show br0
bridge name     bridge id               STP enabled     interfaces
br0             8000.005043020202       no              lan1
                                                        lan2
                                                        lan3
                                                        lan4
                                                        lan5
                                                        lan6
root@clearfog:~# ip addr show|grep 192.168.254
root@clearfog:~# ip addr add 192.168.254.3/24 dev br0
root@clearfog:~# ping 192.168.254.2
PING 192.168.254.2 (192.168.254.2) 56(84) bytes of data.
64 bytes from 192.168.254.2: icmp_seq=1 ttl=255 time=0.648 ms
^C
--- 192.168.254.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.648/0.648/0.648/0.000 ms
root@clearfog:~# ip addr del 192.168.254.3/24 dev br0
root@clearfog:~# brctl delif br0 lan1
root@clearfog:~# ip addr add 192.168.254.3/24 dev lan1
root@clearfog:~# ping 192.168.254.2
PING 192.168.254.2 (192.168.254.2) 56(84) bytes of data.
64 bytes from 192.168.254.2: icmp_seq=1 ttl=255 time=0.331 ms
^C
--- 192.168.254.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.331/0.331/0.331/0.000 ms
root@clearfog:~# ip addr del 192.168.254.3/24 dev lan1
root@clearfog:~# brctl addif br0 lan1
root@clearfog:~# ip addr add 192.168.254.3/24 dev br0
root@clearfog:~# ping 192.168.254.2
PING 192.168.254.2 (192.168.254.2) 56(84) bytes of data.
64 bytes from 192.168.254.2: icmp_seq=1 ttl=255 time=0.630 ms
^C
--- 192.168.254.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.630/0.630/0.630/0.000 ms

I have no other patches for DSA other than the v2 I posted on this
kernel.

I'd suggest adding back the debugfs register dumping so you can get
some diagnostics, and work out what's different in the configuration
between a working kernel and a non-working kernel:

https://github.com/vivien/linux/commit/b23c6568011c84b80a8f5632ac819a5dbdca2dc1.patch

However, what I do notice is that trying to use vlans is a complete
fail - the switch strips _all_ vlan tags off the outgoing packets
no matter how I setup a vlan, whether it's on br0, or on a switch
port:

Packet as observed on a host connected to the switch port with no
vlan capability:
         0x0000:  ffff ffff ffff 0050 4302 0202 0806 0001
         0x0010:  0800 0604 0001 0050 4302 0202 c0a8 fe03 ...

Packet observed on Armada 388's eth interface connected to the 88E6176
switch:
         0x0000:  ffff ffff ffff 0050 4302 0202 dada 0000
         0x0010:  6030 0800 0806 0001 0800 0604 0001 0050 ...

The packet should appear on the wire with the 8100 0800 vlan protocol
ID + tag, but it appears with the vlan protocol and tag stripped.  So
there's yet more issues here.

Incoming packets from the interface appear to be dropped as far as I
can tell - the response to those ARP packets doesn't appear, though
I'm not convinced that I've been able to get the only vlan-capable
device on that side of the network to be setup correctly for vlans -
but obviously it's a total loss if vlan transmission isn't working.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] net: dsa: fix mv88e6xxx switches
  2016-01-23 19:06   ` Russell King - ARM Linux
@ 2016-01-23 19:37     ` Andrew Lunn
  2016-01-23 19:48       ` Russell King - ARM Linux
  0 siblings, 1 reply; 11+ messages in thread
From: Andrew Lunn @ 2016-01-23 19:37 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: Vivien Didelot, netdev

On Sat, Jan 23, 2016 at 07:06:22PM +0000, Russell King - ARM Linux wrote:
> On Sat, Jan 23, 2016 at 07:15:26PM +0100, Andrew Lunn wrote:
> > Thanks for digging into this.
> 
> I hope you saw v2, which is functionally identical.

No, not yet. I will go look for it.
 
> > I think this is a step towards a solution, but does not solve all the
> > problems.
> > 
> > e.g. I have a switch interface lan0 with the IP address
> > 192.168.10.2. I can ping this address from another host. I then take
> > the IP address off the interface, create a br0 device, add lan0 to the
> > bridge, and put 192.168.10.2 onto the bridge. I should be able to then
> > ping the address. But it does not work.
> 
> That works for me.  Maybe it's differences in the switch device?  I
> seem to remember you said your switch was an older generation than
> mine (88E6176).

I'm testing on a 6172. But 6172 and 6176 are both in the same family
6352, and share the same driver.

> root@clearfog:~# brctl show br0
> bridge name     bridge id               STP enabled     interfaces
> br0             8000.005043020202       no              lan1
>                                                         lan2
>                                                         lan3
>                                                         lan4
>                                                         lan5
>                                                         lan6

So you initially have lan1 in an bridge. I don't.

root@370-rd:~# ip link set lan0 up                                                             
root@370-rd:~# ip addr add 192.168.10.2/24 dev lan0                                            
root@370-rd:~# ping 192.168.10.1                                                
PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.                          
64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=1.69 ms                      
64 bytes from 192.168.10.1: icmp_seq=2 ttl=64 time=0.953 ms                     
64 bytes from 192.168.10.1: icmp_seq=3 ttl=64 time=0.926 ms    

root@370-rd:~# ip addr del 192.168.10.2/24 dev lan0
root@370-rd:~# brctl addbr br0
root@370-rd:~# brctl addif br0 lan0
root@370-rd:~# ip link set br0 up
root@370-rd:~# ip addr add 192.168.10.2/24 dev br0                              
root@370-rd:~# ping 192.168.10.1                                                
PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.                          
^C                                                                              
--- 192.168.10.1 ping statistics ---                                            
3 packets transmitted, 0 received, 100% packet loss, time 2001ms    

  Andrew

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] net: dsa: fix mv88e6xxx switches
  2016-01-23 19:37     ` Andrew Lunn
@ 2016-01-23 19:48       ` Russell King - ARM Linux
  2016-01-23 20:16         ` Andrew Lunn
  0 siblings, 1 reply; 11+ messages in thread
From: Russell King - ARM Linux @ 2016-01-23 19:48 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: Vivien Didelot, netdev

On Sat, Jan 23, 2016 at 08:37:05PM +0100, Andrew Lunn wrote:
> I'm testing on a 6172. But 6172 and 6176 are both in the same family
> 6352, and share the same driver.

Hmm, can't be that then.

> So you initially have lan1 in an bridge. I don't.

Okay, I've disabled br0 in the debian network/interfaces and rebooted.
This means eth0 (connected to the bridge) is initially down, along with
all the lan interfaces.

root@clearfog:~# brctl show br0
bridge name     bridge id               STP enabled     interfaces
br0             can't get info No such device
root@clearfog:~# ip link set eth0 up
root@clearfog:~# ip link set lan5 up
root@clearfog:~# ip addr add 192.168.254.3/24 dev lan5
root@clearfog:~# ping 192.168.254.254
PING 192.168.254.254 (192.168.254.254) 56(84) bytes of data.
64 bytes from 192.168.254.254: icmp_seq=1 ttl=64 time=1.15 ms
64 bytes from 192.168.254.254: icmp_seq=2 ttl=64 time=0.686 ms
^C
--- 192.168.254.254 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.686/0.921/1.157/0.237 ms
root@clearfog:~# ip addr del 192.168.254.3/24 dev lan5
root@clearfog:~# brctl addbr br0
root@clearfog:~# brctl addif br0 lan5
root@clearfog:~# ip link set br0 up
root@clearfog:~# ip addr add 192.168.254.3/24 dev br0
root@clearfog:~# ping 192.168.254.254
PING 192.168.254.254 (192.168.254.254) 56(84) bytes of data.
64 bytes from 192.168.254.254: icmp_seq=1 ttl=64 time=1.18 ms
^C
--- 192.168.254.254 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.189/1.189/1.189/0.000 ms

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] net: dsa: fix mv88e6xxx switches
  2016-01-23 19:48       ` Russell King - ARM Linux
@ 2016-01-23 20:16         ` Andrew Lunn
  2016-01-23 20:44           ` Russell King - ARM Linux
  0 siblings, 1 reply; 11+ messages in thread
From: Andrew Lunn @ 2016-01-23 20:16 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: Vivien Didelot, netdev

On Sat, Jan 23, 2016 at 07:48:57PM +0000, Russell King - ARM Linux wrote:
> On Sat, Jan 23, 2016 at 08:37:05PM +0100, Andrew Lunn wrote:
> > I'm testing on a 6172. But 6172 and 6176 are both in the same family
> > 6352, and share the same driver.
> 
> Hmm, can't be that then.
> 
> > So you initially have lan1 in an bridge. I don't.

Running tcpdump on the device i'm trying to ping, there are ARP
requests and replies. But the replies are never received by the
target, arp -a shows <incomplete>.

Looking at the stats counters in debugfs, the packets are counted in
in_unicast, but also sw_in_filtered.

Port 0 is lan0 and port 5 is the cpu port.

root@370-rd:/sys/kernel/debug/dsa0# cat regs
    GLOBAL GLOBAL2 SERDES   0    1    2    3    4    5    6  
 0:  c874       0    1940  1d0f 1d0f 1d0f 1d0f 100f  e07    6 
 1:   fa0       0     149     3    3    3    3    3 c03e    3 
 2:   fa0    ffff     141     0    0    0    0    0    0    0 
 3:     0    ffff     ea1  1721 1721 1721 1721 1721 1721 1721 
 4:  6000     258     1e0   433  433  433  433  433 373f  433 
 5:  3000      ff       0     0    0    0    0    0    0    0 
 6:   fa0    1f0f       4    7f   7e   7d   7c   7b   7a   79 
 7:  3331    707f    2001     0  fa1  fa2  fa3  fa4    0  fa6 
 8:   303    7800       0  2c80 2c80 2c80 2c80 2c80 2c80 2c80 
 9:     0    1600       0     1    1    1    1    1    1    1 
 a:   148       0       0     0    0    0    0    0    0    0 
 b:  2000    1000       0     1    2    4    8   10 2000   40 
 c:   f0f      7f       0     0    0    0    0    0    0    0 
 d:     0     5f1       3     0    0    0    0    0    0    0 
 e:     0       0       0     0    0    0    0    0    0    0 
 f:     0     f00    c000  dada dada dada dada dada dada dada 
10:     0       0    4005     0    0    0    0    0    0    0 
11:     0       0    8000     0    0    0    0    0    0    0 
12:  5555       0       0    12    0    0    0    0    8    0 
13:  5555       0       0     0    0    0    0    0   22    0 
14:  aaaa     400       0     0    0    0    0    0    0    0 
15:  aaaa       0       0     0    0    0    0    0    0    0 
16:  ffff       0       1  700f 7002 7004 7008   33   33    0 
17:  ffff       0       0     0    0    0    0    0    0    0 
18:  fa41    15f6       0  3210 3210 3210 3210 3210 3210 3210 
19:     0       0       0  7654 7654 7654 7654 7654 7654 7654 
1a:  5550       0      42     0    0    0    0    0    0    0 
1b:   1fa    f869       0  8000 8000 8000 8000 8000 8000 8000 
1c:     0       0       0     0    0    0    0    0    0    0 
1d:  5ce0       0       0     0    0    0    0    0    0    0 
1e:     0       0       0     0    0    0    0    0    0    0 
1f:     0       0       0     0    0    0    0    0    0    0 

	Andrew

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] net: dsa: fix mv88e6xxx switches
  2016-01-23 20:16         ` Andrew Lunn
@ 2016-01-23 20:44           ` Russell King - ARM Linux
  2016-01-23 22:12             ` Andrew Lunn
  0 siblings, 1 reply; 11+ messages in thread
From: Russell King - ARM Linux @ 2016-01-23 20:44 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: Vivien Didelot, netdev

On Sat, Jan 23, 2016 at 09:16:47PM +0100, Andrew Lunn wrote:
> On Sat, Jan 23, 2016 at 07:48:57PM +0000, Russell King - ARM Linux wrote:
> > On Sat, Jan 23, 2016 at 08:37:05PM +0100, Andrew Lunn wrote:
> > > I'm testing on a 6172. But 6172 and 6176 are both in the same family
> > > 6352, and share the same driver.
> > 
> > Hmm, can't be that then.
> > 
> > > So you initially have lan1 in an bridge. I don't.
> 
> Running tcpdump on the device i'm trying to ping, there are ARP
> requests and replies. But the replies are never received by the
> target, arp -a shows <incomplete>.
> 
> Looking at the stats counters in debugfs, the packets are counted in
> in_unicast, but also sw_in_filtered.
> 
> Port 0 is lan0 and port 5 is the cpu port.
> 
> root@370-rd:/sys/kernel/debug/dsa0# cat regs
>     GLOBAL GLOBAL2 SERDES   0    1    2    3    4    5    6  
>  0:  c874       0    1940  1d0f 1d0f 1d0f 1d0f 100f  e07    6 
>  1:   fa0       0     149     3    3    3    3    3 c03e    3 
>  2:   fa0    ffff     141     0    0    0    0    0    0    0 
>  3:     0    ffff     ea1  1721 1721 1721 1721 1721 1721 1721 
>  4:  6000     258     1e0   433  433  433  433  433 373f  433 
>  5:  3000      ff       0     0    0    0    0    0    0    0 
>  6:   fa0    1f0f       4    7f   7e   7d   7c   7b   7a   79 
>  7:  3331    707f    2001     0  fa1  fa2  fa3  fa4    0  fa6 

This shows port 0 is on vlan 0, but it should default to vlan 1 when
no vlans are configured.  The patch below should at least allow some
diagnosis of what's being requested, and when.

diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index a43354ed0607..8a9cf67eb16d 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -1511,6 +1511,9 @@ int mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port,
 	u16 vid;
 	int err = 0;
 
+	printk("%s: port %d vid %u-%u flags %x\n",
+		__func__, port, vlan->vid_begin, vlan->vid_end, vlan->flags);
+
 	mutex_lock(&ps->smi_mutex);
 
 	for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {


-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCH] net: dsa: fix mv88e6xxx switches
  2016-01-23 20:44           ` Russell King - ARM Linux
@ 2016-01-23 22:12             ` Andrew Lunn
  2016-01-23 22:23               ` Andrew Lunn
  0 siblings, 1 reply; 11+ messages in thread
From: Andrew Lunn @ 2016-01-23 22:12 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: Vivien Didelot, netdev

> This shows port 0 is on vlan 0, but it should default to vlan 1 when
> no vlans are configured.  The patch below should at least allow some
> diagnosis of what's being requested, and when.
> 
> diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
> index a43354ed0607..8a9cf67eb16d 100644
> --- a/drivers/net/dsa/mv88e6xxx.c
> +++ b/drivers/net/dsa/mv88e6xxx.c
> @@ -1511,6 +1511,9 @@ int mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port,
>  	u16 vid;
>  	int err = 0;
>  
> +	printk("%s: port %d vid %u-%u flags %x\n",
> +		__func__, port, vlan->vid_begin, vlan->vid_end, vlan->flags);
> +

Hi Russell

Never called.

So i guess we have a kernel configuration difference.

I don't have CONFIG_BRIDGE_VLAN_FILTERING.

But DSA should not rely on this option for correct operation.

  Andrew

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] net: dsa: fix mv88e6xxx switches
  2016-01-23 22:12             ` Andrew Lunn
@ 2016-01-23 22:23               ` Andrew Lunn
  2016-01-23 23:31                 ` Russell King - ARM Linux
  0 siblings, 1 reply; 11+ messages in thread
From: Andrew Lunn @ 2016-01-23 22:23 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: Vivien Didelot, netdev

On Sat, Jan 23, 2016 at 11:12:32PM +0100, Andrew Lunn wrote:
> > This shows port 0 is on vlan 0, but it should default to vlan 1 when
> > no vlans are configured.  The patch below should at least allow some
> > diagnosis of what's being requested, and when.
> > 
> > diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
> > index a43354ed0607..8a9cf67eb16d 100644
> > --- a/drivers/net/dsa/mv88e6xxx.c
> > +++ b/drivers/net/dsa/mv88e6xxx.c
> > @@ -1511,6 +1511,9 @@ int mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port,
> >  	u16 vid;
> >  	int err = 0;
> >  
> > +	printk("%s: port %d vid %u-%u flags %x\n",
> > +		__func__, port, vlan->vid_begin, vlan->vid_end, vlan->flags);
> > +
> 
> Hi Russell
> 
> Never called.
> 
> So i guess we have a kernel configuration difference.
> 
> I don't have CONFIG_BRIDGE_VLAN_FILTERING.

Yep, confirmed. When i enable this option, and VLAN_8021Q which it
depends on, i then have a working bridge.

	Andrew

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] net: dsa: fix mv88e6xxx switches
  2016-01-23 22:23               ` Andrew Lunn
@ 2016-01-23 23:31                 ` Russell King - ARM Linux
  2016-01-24  6:01                   ` Vivien Didelot
  0 siblings, 1 reply; 11+ messages in thread
From: Russell King - ARM Linux @ 2016-01-23 23:31 UTC (permalink / raw)
  To: Andrew Lunn, Vivien Didelot; +Cc: netdev

On Sat, Jan 23, 2016 at 11:23:26PM +0100, Andrew Lunn wrote:
> On Sat, Jan 23, 2016 at 11:12:32PM +0100, Andrew Lunn wrote:
> > Hi Russell
> > 
> > Never called.
> > 
> > So i guess we have a kernel configuration difference.
> > 
> > I don't have CONFIG_BRIDGE_VLAN_FILTERING.
> 
> Yep, confirmed. When i enable this option, and VLAN_8021Q which it
> depends on, i then have a working bridge.

It sounds like Vivien urgently needs to do some extra work to fix
the patches that created all this broken-ness, or we need to ask
davem to revert back to a known good working state.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] net: dsa: fix mv88e6xxx switches
  2016-01-23 23:31                 ` Russell King - ARM Linux
@ 2016-01-24  6:01                   ` Vivien Didelot
  0 siblings, 0 replies; 11+ messages in thread
From: Vivien Didelot @ 2016-01-24  6:01 UTC (permalink / raw)
  To: Russell King - ARM Linux, Andrew Lunn; +Cc: netdev

Hi Russell,

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

> On Sat, Jan 23, 2016 at 11:23:26PM +0100, Andrew Lunn wrote:
>> On Sat, Jan 23, 2016 at 11:12:32PM +0100, Andrew Lunn wrote:
>> > Hi Russell
>> > 
>> > Never called.
>> > 
>> > So i guess we have a kernel configuration difference.
>> > 
>> > I don't have CONFIG_BRIDGE_VLAN_FILTERING.
>> 
>> Yep, confirmed. When i enable this option, and VLAN_8021Q which it
>> depends on, i then have a working bridge.
>
> It sounds like Vivien urgently needs to do some extra work to fix
> the patches that created all this broken-ness, or we need to ask
> davem to revert back to a known good working state.

Indeed hardware bridging currently relies on 802.1Q and VLAN filtering
enabled. I will work on this asap.

Thanks,
-v

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2016-01-24  6:01 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-23 10:51 [PATCH] net: dsa: fix mv88e6xxx switches Russell King
2016-01-23 18:15 ` Andrew Lunn
2016-01-23 19:06   ` Russell King - ARM Linux
2016-01-23 19:37     ` Andrew Lunn
2016-01-23 19:48       ` Russell King - ARM Linux
2016-01-23 20:16         ` Andrew Lunn
2016-01-23 20:44           ` Russell King - ARM Linux
2016-01-23 22:12             ` Andrew Lunn
2016-01-23 22:23               ` Andrew Lunn
2016-01-23 23:31                 ` Russell King - ARM Linux
2016-01-24  6:01                   ` Vivien Didelot

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.