net: dsa: sja1105: Limit use of incl_srcpt to bridge+vlan mode
authorVladimir Oltean <olteanv@gmail.com>
Sat, 8 Jun 2019 12:04:32 +0000 (15:04 +0300)
committerDavid S. Miller <davem@davemloft.net>
Sat, 8 Jun 2019 22:20:40 +0000 (15:20 -0700)
commit42824463d38d273194376051d7883724aea1b0ac
treeed29c4d66c66a42c0cfe7a825a0ab5bea6b2829f
parentf9a1a7646c0d8351a2529b221c4f5fa46b384ee6
net: dsa: sja1105: Limit use of incl_srcpt to bridge+vlan mode

The incl_srcpt setting makes the switch mangle the destination MACs of
multicast frames trapped to the CPU - a primitive tagging mechanism that
works even when we cannot use the 802.1Q software features.

The downside is that the two multicast MAC addresses that the switch
traps for L2 PTP (01-80-C2-00-00-0E and 01-1B-19-00-00-00) quickly turn
into a lot more, as the switch encodes the source port and switch id
into bytes 3 and 4 of the MAC. The resulting range of MAC addresses
would need to be installed manually into the DSA master port's multicast
MAC filter, and even then, most devices might not have a large enough
MAC filtering table.

As a result, only limit use of incl_srcpt to when it's strictly
necessary: when under a VLAN filtering bridge.  This fixes PTP in
non-bridged mode (standalone ports). Otherwise, PTP frames, as well as
metadata follow-up frames holding RX timestamps won't be received
because they will be blocked by the master port's MAC filter.
Linuxptp doesn't help, because it only requests the addition of the
unmodified PTP MACs to the multicast filter.
This issue is not seen in bridged mode because the master port is put in
promiscuous mode when the slave ports are enslaved to a bridge.
Therefore, there is no downside to having the incl_srcpt mechanism
active there.

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