diff options
author | Vivien Didelot <vivien.didelot@savoirfairelinux.com> | 2015-10-12 01:08:38 +0300 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2015-10-13 14:26:31 +0300 |
commit | 5fe7f68016ff9dcb59632071f9abf30296bbad3c (patch) | |
tree | fe2d3cf9b665b6d6caaa5d3068fd2d5e509ace27 /net/switchdev/switchdev.c | |
parent | efd29b3d8266761570fd3f440e2d5aa24c678725 (diff) | |
download | linux-5fe7f68016ff9dcb59632071f9abf30296bbad3c.tar.xz |
net: dsa: mv88e6xxx: fix hardware bridging
Playing with the VLAN map of every port to implement "hardware bridging"
in the 88E6352 driver was a hack until full 802.1Q was supported.
Indeed with 802.1Q port mode "Disabled" or "Fallback", this feature is
used to restrict which output ports an input port can egress frames to.
A Linux bridge is an untagged VLAN. With full 802.1Q support, we don't
need this hack anymore and can use the "Secure" strict 802.1Q port mode.
With this mode, the port-based VLAN map still needs to be configured,
but all the logic is VTU-centric. This means that the switch only cares
about rules described in its hardware VLAN table, which is exactly what
Linux bridge expects and what we want.
Note also that the hardware bridging was broken with the previous
flexible "Fallback" 802.1Q port mode. Here's an example:
Port0 and Port1 belong to the same bridge. If Port0 sends crafted tagged
frames with VID 200 to Port1, Port1 receives it. Even if Port1 is in
hardware VLAN 200, but not Port0, Port1 will still receive it, because
Fallback mode doesn't care about invalid VID or non-member source port.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/switchdev/switchdev.c')
0 files changed, 0 insertions, 0 deletions