moonjuice/kernel_arpi
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

net: dsa: tag_sja1105: stop asking the sja1105 driver in sja1105_xmit_tpid

Browse Source 
Introduced in commit 38b5beeae7 ("net: dsa: sja1105: prepare tagger
for handling DSA tags and VLAN simultaneously"), the sja1105_xmit_tpid
function solved quite a different problem than our needs are now.

Then, we used best-effort VLAN filtering and we were using the xmit_tpid
to tunnel packets coming from an 8021q upper through the TX VLAN allocated
by tag_8021q to that egress port. The need for a different VLAN protocol
depending on switch revision came from the fact that this in itself was
more of a hack to trick the hardware into accepting tunneled VLANs in
the first place.

Right now, we deny 8021q uppers (see sja1105_prechangeupper). Even if we
supported them again, we would not do that using the same method of
{tunneling the VLAN on egress, retagging the VLAN on ingress} that we
had in the best-effort VLAN filtering mode. It seems rather simpler that
we just allocate a VLAN in the VLAN table that is simply not used by the
bridge at all, or by any other port.

Anyway, I have 2 gripes with the current sja1105_xmit_tpid:

1. When sending packets on behalf of a VLAN-aware bridge (with the new
   TX forwarding offload framework) plus untagged (with the tag_8021q
   VLAN added by the tagger) packets, we can see that on SJA1105P/Q/R/S
   and later (which have a qinq_tpid of ETH_P_8021AD), some packets sent
   through the DSA master have a VLAN protocol of 0x8100 and others of
   0x88a8. This is strange and there is no reason for it now. If we have
   a bridge and are therefore forced to send using that bridge's TPID,
   we can as well blend with that bridge's VLAN protocol for all packets.

2. The sja1105_xmit_tpid introduces a dependency on the sja1105 driver,
   because it looks inside dp->priv. It is desirable to keep as much
   separation between taggers and switch drivers as possible. Now it
   doesn't do that anymore.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:
Vladimir Oltean
2021-08-24 20:15:02 +03:00
committed by David S. Miller
parent b0b8c67eaa
commit 8ded916092
5 changed files with 34 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
net/dsa/tag_sja1105.c
View File

@@ -133,14 +133,44 @@ static struct sk_buff *sja1105_defer_xmit(struct dsa_port *dp,
return NULL;
}
/* Send VLAN tags with a TPID that blends in with whatever VLAN protocol a
* bridge spanning ports of this switch might have.
*/
static u16 sja1105_xmit_tpid(struct dsa_port *dp)
{
struct sja1105_port *sp = dp->priv;
struct dsa_switch *ds = dp->ds;
struct dsa_port *other_dp;
u16 proto;
if (unlikely(!dsa_port_is_sja1105(dp)))
return ETH_P_8021Q;
/* Since VLAN awareness is global, then if this port is VLAN-unaware,
* all ports are. Use the VLAN-unaware TPID used for tag_8021q.
*/
if (!dsa_port_is_vlan_filtering(dp))
return ETH_P_SJA1105;
return sp->xmit_tpid;
/* Port is VLAN-aware, so there is a bridge somewhere (a single one,
* we're sure about that). It may not be on this port though, so we
* need to find it.
*/
list_for_each_entry(other_dp, &ds->dst->ports, list) {
if (other_dp->ds != ds)
continue;
if (!other_dp->bridge_dev)
continue;
/* Error is returned only if CONFIG_BRIDGE_VLAN_FILTERING,
* which seems pointless to handle, as our port cannot become
* VLAN-aware in that case.
*/
br_vlan_get_proto(other_dp->bridge_dev, &proto);
return proto;
}
WARN_ONCE(1, "Port is VLAN-aware but cannot find associated bridge!\n");
return ETH_P_SJA1105;
}
static struct sk_buff *sja1105_imprecise_xmit(struct sk_buff *skb,