From: Vladimir Oltean Date: Tue, 16 Mar 2021 11:24:13 +0000 (+0200) Subject: Documentation: networking: dsa: document the port_bridge_flags method X-Git-Tag: v5.13-rc1~94^2~524^2~6 X-Git-Url: http://git.osdn.net/view?a=commitdiff_plain;h=5a275f4c2989f6f1fab626c61d34001f28381a18;p=tomoyo%2Ftomoyo-test1.git Documentation: networking: dsa: document the port_bridge_flags method The documentation was already lagging behind by not mentioning the old version of port_bridge_flags (port_set_egress_floods). So now we are skipping one step and just explaining how a DSA driver should configure address learning and flooding settings. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller --- diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index b90a852e5329..9c287dfd3c45 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -619,6 +619,17 @@ Bridge layer computing a STP state change based on current and asked parameters and perform the relevant ageing based on the intersection results +- ``port_bridge_flags``: bridge layer function invoked when a port must + configure its settings for e.g. flooding of unknown traffic or source address + learning. The switch driver is responsible for initial setup of the + standalone ports with address learning disabled and egress flooding of all + types of traffic, then the DSA core notifies of any change to the bridge port + flags when the port joins and leaves a bridge. DSA does not currently manage + the bridge port flags for the CPU port. The assumption is that address + learning should be statically enabled (if supported by the hardware) on the + CPU port, and flooding towards the CPU port should also be enabled, due to a + lack of an explicit address filtering mechanism in the DSA core. + Bridge VLAN filtering ---------------------