Re: [PATCH net-next 2/3] net: dsa: mv88e6xxx: fix duplicate vlan warning

[Russell King - ARM Linux admin <linux@armlinux.org.uk>]

On Tue, Feb 18, 2020 at 05:27:50PM +0100, Andrew Lunn wrote:
> On Tue, Feb 18, 2020 at 11:51:57AM +0000, Russell King - ARM Linux admin wrote:
> > On Tue, Feb 18, 2020 at 11:46:14AM +0000, Russell King wrote:
> > > When setting VLANs on DSA switches, the VLAN is added to both the port
> > > concerned as well as the CPU port by dsa_slave_vlan_add().  If multiple
> > > ports are configured with the same VLAN ID, this triggers a warning on
> > > the CPU port.
> > > 
> > > Avoid this warning for CPU ports.
> > > 
> > > Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > 
> > Note that there is still something not right.  On the ZII dev rev B,
> > setting up a bridge across all the switch ports, I get:
> 
> Hi Russell
> 
> FYI: You need to be a little careful with VLANs on rev B. The third
> switch does not have the PVT hardware. So VLANs are going to 'leak'
> when they cross the DSA link to that switch.

I'm not sure I fully understand what you're saying or the mechanism
behind it.

From what I can see, the 88E6352 and the 88E6185 both contain a VTU
which is capable of taking an ingressing frame and restricting which
ports it can egress from.

If a frame ingresses on one 88E6352, passed across to the other
88E6352, and finally to the 88E6185, doesn't each switch look up in
its own VTU which ports to egress the packet from, which should
include the DSA ports, so it can then be passed to the other switches?
And doesn't the VTU on each switch define which ports the frame is
allowed to egress out of?

From what I can see, setting up a bridge across all lan ports on the
Zii rev B, then enabling vlan filtering, and then allowing VID V on
lan0 and lan8 (one port on each 88E6352, passed across to the other
88E6352, and finally to the 88E6185 which has the other port on)
results in VID V frames passed correctly across, and are received
appropriately.  Untagged traffic continues to be received
appropriately.

Removing VID V from lan8 (the port I'm monitoring) results in VID V
traffic no longer sent out via lan8.

So, it seems to work as one would expect.

What am I missing?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up