summaryrefslogtreecommitdiff
path: root/net/dsa/tag_8021q.c
diff options
context:
space:
mode:
authorVladimir Oltean <vladimir.oltean@nxp.com>2020-05-12 20:20:28 +0300
committerDavid S. Miller <davem@davemloft.net>2020-05-12 13:08:08 -0700
commit60b33aeb7e0e664865ace822c0a7aeeb5ebe521c (patch)
tree741eb60869531642d7d47f0e7a92e3338c3d2b5a /net/dsa/tag_8021q.c
parent7f14937facdca1e0da1bacfacd089bcf4271e75a (diff)
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>
Diffstat (limited to 'net/dsa/tag_8021q.c')
0 files changed, 0 insertions, 0 deletions