diff mbox series

[RFC,net-next,06/12] Documentation: networking: dsa: document the port_bridge_flags method

Message ID 20210221213355.1241450-7-olteanv@gmail.com (mailing list archive)
State RFC
Delegated to: Netdev Maintainers
Headers show
Series Documentation updates for switchdev and DSA | expand

Checks

Context Check Description
netdev/cover_letter success Link
netdev/fixes_present success Link
netdev/patch_count success Link
netdev/tree_selection success Clearly marked for net-next
netdev/subject_prefix success Link
netdev/cc_maintainers warning 6 maintainers not CCed: linux-doc@vger.kernel.org kuba@kernel.org corbet@lwn.net davem@davemloft.net vladimir.oltean@nxp.com rdunlap@infradead.org
netdev/source_inline success Was 0 now: 0
netdev/verify_signedoff success Link
netdev/module_param success Was 0 now: 0
netdev/build_32bit success Errors and warnings before: 0 this patch: 0
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/verify_fixes success Link
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 17 lines checked
netdev/build_allmodconfig_warn success Errors and warnings before: 0 this patch: 0
netdev/header_inline success Link
netdev/stable success Stable not CCed

Commit Message

Vladimir Oltean Feb. 21, 2021, 9:33 p.m. UTC 
From: Vladimir Oltean <vladimir.oltean@nxp.com>

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 <vladimir.oltean@nxp.com>
---
 Documentation/networking/dsa/dsa.rst | 11 +++++++++++
 1 file changed, 11 insertions(+)

Comments

Florian Fainelli Feb. 22, 2021, 5:15 a.m. UTC | #1 
On 2/21/2021 13:33, Vladimir Oltean wrote:
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
> 
> 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 <vladimir.oltean@nxp.com>

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Andrew Lunn Feb. 25, 2021, 1:14 a.m. UTC | #2 
> +  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, in lack
> +  of an explicit address filtering mechanism in the DSA core.

Hi Vladimir

"in lack of" is a bit odd wording. Maybe "due to a lack of"

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew
diff mbox series

Patch

diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst
index 19ce5bb0a7a4..3c6560a43ae0 100644
--- a/Documentation/networking/dsa/dsa.rst
+++ b/Documentation/networking/dsa/dsa.rst
@@ -597,6 +597,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, in lack
+  of an explicit address filtering mechanism in the DSA core.
+
 Bridge VLAN filtering
 ---------------------