net: dsa: sja1105: deny alterations of dsa_8021q VLANs from the bridge
authorVladimir Oltean <vladimir.oltean@nxp.com>
Tue, 12 May 2020 17:20:28 +0000 (20:20 +0300)
committerDavid S. Miller <davem@davemloft.net>
Tue, 12 May 2020 20:08:08 +0000 (13:08 -0700)
commit60b33aeb7e0e664865ace822c0a7aeeb5ebe521c
tree741eb60869531642d7d47f0e7a92e3338c3d2b5a
parent7f14937facdca1e0da1bacfacd089bcf4271e75a
net: dsa: sja1105: deny alterations of dsa_8021q VLANs from the bridge

At the moment, this can never happen. The 2 modes that we operate in do
not permit that:

 - SJA1105_VLAN_UNAWARE: we are guarded from bridge VLANs added by the
   user by the DSA core. We will later lift this restriction by setting
   ds->vlan_bridge_vtu = true, and that is where we'll need it.

 - SJA1105_VLAN_FILTERING_FULL: in this mode, dsa_8021q configuration is
   disabled. So the user is free to add these VLANs in the 1024-3071
   range.

The reason for the patch is that we'll introduce a third VLAN awareness
state, where both dsa_8021q as well as the bridge are going to call our
.port_vlan_add and .port_vlan_del methods.

For that, we need a good way to discriminate between the 2. The easiest
(and less intrusive way for upper layers) is to recognize the fact that
dsa_8021q configurations are always driven by our driver - we _know_
when a .port_vlan_add method will be called from dsa_8021q because _we_
initiated it.

So introduce an expect_dsa_8021q boolean which is only used, at the
moment, for blacklisting VLANs in range 1024-3071 in the modes when
dsa_8021q is active.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
drivers/net/dsa/sja1105/sja1105.h
drivers/net/dsa/sja1105/sja1105_main.c