On 5/5/2019 2:15 PM, Hauke Mehrtens wrote:
> The VLAN aware bridge offloading is similar to the VLAN unaware
> offloading, this makes it possible to offload the VLAN bridge
> functionalities.
>
> The hardware supports up to 64 VLAN bridge entries, we already use one
> entry for each LAN port to prevent forwarding of packets between the
> ports when the ports are not in a bridge, so in the end we have 57
> possible VLANs.
>
> The VLAN filtering is currently only active when the ports are in a
> bridge, VLAN filtering for ports not in a bridge is not implemented.
>
> It is currently not possible to change between VLAN filtering and not
> filtering while the port is already in a bridge, this would make the
> driver more complicated.
>
> The VLANs are only defined on bridge entries, so we will not add
> anything into the hardware when the port joins a bridge if it is doing
> VLAN filtering, but only when an allowed VLAN is added.
[snip]
> struct gswip_priv *priv = ds->priv;
> + struct net_device *bridge = dsa_to_port(ds, port)->bridge_dev;
> +
> + /* Do not allow chaning the VLAN filtering options while in bridge */
Typo: changing.
This looks fine to me, you might be able to simplify the code a little
bit if you directly used bridge_dev->ifindex as the FID and just keep a
bitmap of active FIDs such that you can manage roll-overs etc. upon
bridge device destruction/creation.
Reviewed-by: Florian Fainelli <f.faine...@gmail.com>
--
Florian
