summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/mscc/ocelot.c
diff options
context:
space:
mode:
authorVladimir Oltean <vladimir.oltean@nxp.com>2022-05-05 19:22:11 +0300
committerJakub Kicinski <kuba@kernel.org>2022-05-06 21:00:12 -0700
commita51c1c3f3218c74c07fed55ea2ad5b18c374dc25 (patch)
treeabe8f7064339085238f8a103562260fda933af96 /drivers/net/ethernet/mscc/ocelot.c
parent2c110abc46168c3a8cc9f855c986a55650c777dd (diff)
net: dsa: felix: stop migrating FDBs back and forth on tag proto change
I just realized we don't need to migrate the host-filtered FDB entries when the tagging protocol changes from "ocelot" to "ocelot-8021q". Host-filtered addresses are learned towards the PGID_CPU "multicast" port group, reserved by software, which contains BIT(ocelot->num_phys_ports). That is the "special" port entry in the analyzer block for the CPU port module. In "ocelot" mode, the CPU port module's packets are redirected to the NPI port. In "ocelot-8021q" mode, felix_8021q_cpu_port_init() does something funny anyway, and changes PGID_CPU to stop pointing at the CPU port module and start pointing at the physical port where the DSA master is attached. The fact that we can alter the destination of packets learned towards PGID_CPU without altering the MAC table entries themselves means that it is pointless to walk through the FDB entries, forget that they were learned towards PGID_CPU, and re-learn them towards the "unicast" PGID associated with the physical port connected to the DSA master. We can let the PGID_CPU value change simply alter the destination of the host-filtered unicast packets in one fell swoop. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'drivers/net/ethernet/mscc/ocelot.c')
0 files changed, 0 insertions, 0 deletions