mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-28 07:04:00 +08:00
9264e4ad26
Currently, when DSA performs fast ageing on a port, 'bridge fdb' shows us that the 'self' entries (corresponding to the hardware bridge, as printed by dsa_slave_fdb_dump) are deleted, but the 'master' entries (corresponding to the software bridge) aren't. Indeed, searching through the bridge driver, neither the brport_attr_learning handler nor the IFLA_BRPORT_LEARNING handler call br_fdb_delete_by_port. However, br_stp_disable_port does, which is one of the paths which DSA uses to trigger a fast ageing process anyway. There is, however, one other very promising caller of br_fdb_delete_by_port, and that is the bridge driver's handler of the SWITCHDEV_FDB_FLUSH_TO_BRIDGE atomic notifier. Currently the s390/qeth HiperSockets card driver is the only user of this. I can't say I understand that driver's architecture or interaction with the bridge, but it appears to not be a switchdev driver in the traditional sense of the word. Nonetheless, the mechanism it provides is a useful way for DSA to express the fact that it performs fast ageing too, in a way that does not change the existing behavior for other drivers. Cc: Alexandra Winter <wintera@linux.ibm.com> Cc: Julian Wiedmann <jwi@linux.ibm.com> Cc: Roopa Prabhu <roopa@nvidia.com> Cc: Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
||
---|---|---|
.. | ||
dsa2.c | ||
dsa_priv.h | ||
dsa.c | ||
Kconfig | ||
Makefile | ||
master.c | ||
port.c | ||
slave.c | ||
switch.c | ||
tag_8021q.c | ||
tag_ar9331.c | ||
tag_brcm.c | ||
tag_dsa.c | ||
tag_gswip.c | ||
tag_hellcreek.c | ||
tag_ksz.c | ||
tag_lan9303.c | ||
tag_mtk.c | ||
tag_ocelot_8021q.c | ||
tag_ocelot.c | ||
tag_qca.c | ||
tag_rtl4_a.c | ||
tag_sja1105.c | ||
tag_trailer.c | ||
tag_xrs700x.c |