Commit f8843991 authored by Vladimir Oltean's avatar Vladimir Oltean Committed by David S. Miller

Documentation: networking: dsa: remove references to switchdev prepare/commit

After the recent series containing commit bae33f2b ("net: switchdev:
remove the transaction structure from port attributes"), there aren't
prepare/commit transactional phases anymore in most of the switchdev
objects/attributes, and as a result, there aren't any in the DSA driver
API either. So remove this piece.
Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parent f23f1404
...@@ -452,14 +452,8 @@ SWITCHDEV ...@@ -452,14 +452,8 @@ SWITCHDEV
DSA directly utilizes SWITCHDEV when interfacing with the bridge layer, and DSA directly utilizes SWITCHDEV when interfacing with the bridge layer, and
more specifically with its VLAN filtering portion when configuring VLANs on top more specifically with its VLAN filtering portion when configuring VLANs on top
of per-port slave network devices. Since DSA primarily deals with of per-port slave network devices. As of today, the only SWITCHDEV objects
MDIO-connected switches, although not exclusively, SWITCHDEV's supported by DSA are the FDB and VLAN objects.
prepare/abort/commit phases are often simplified into a prepare phase which
checks whether the operation is supported by the DSA switch driver, and a commit
phase which applies the changes.
As of today, the only SWITCHDEV objects supported by DSA are the FDB and VLAN
objects.
Device Tree Device Tree
----------- -----------
...@@ -638,14 +632,10 @@ Bridge VLAN filtering ...@@ -638,14 +632,10 @@ Bridge VLAN filtering
accept any 802.1Q frames irrespective of their VLAN ID, and untagged frames are accept any 802.1Q frames irrespective of their VLAN ID, and untagged frames are
allowed. allowed.
- ``port_vlan_prepare``: bridge layer function invoked when the bridge prepares the
configuration of a VLAN on the given port. If the operation is not supported
by the hardware, this function should return ``-EOPNOTSUPP`` to inform the bridge
code to fallback to a software implementation. No hardware setup must be done
in this function. See port_vlan_add for this and details.
- ``port_vlan_add``: bridge layer function invoked when a VLAN is configured - ``port_vlan_add``: bridge layer function invoked when a VLAN is configured
(tagged or untagged) for the given switch port (tagged or untagged) for the given switch port. If the operation is not
supported by the hardware, this function should return ``-EOPNOTSUPP`` to
inform the bridge code to fallback to a software implementation.
- ``port_vlan_del``: bridge layer function invoked when a VLAN is removed from the - ``port_vlan_del``: bridge layer function invoked when a VLAN is removed from the
given switch port given switch port
...@@ -673,14 +663,10 @@ Bridge VLAN filtering ...@@ -673,14 +663,10 @@ Bridge VLAN filtering
function that the driver has to call for each MAC address known to be behind function that the driver has to call for each MAC address known to be behind
the given port. A switchdev object is used to carry the VID and FDB info. the given port. A switchdev object is used to carry the VID and FDB info.
- ``port_mdb_prepare``: bridge layer function invoked when the bridge prepares the
installation of a multicast database entry. If the operation is not supported,
this function should return ``-EOPNOTSUPP`` to inform the bridge code to fallback
to a software implementation. No hardware setup must be done in this function.
See ``port_fdb_add`` for this and details.
- ``port_mdb_add``: bridge layer function invoked when the bridge wants to install - ``port_mdb_add``: bridge layer function invoked when the bridge wants to install
a multicast database entry, the switch hardware should be programmed with the a multicast database entry. If the operation is not supported, this function
should return ``-EOPNOTSUPP`` to inform the bridge code to fallback to a
software implementation. The switch hardware should be programmed with the
specified address in the specified VLAN ID in the forwarding database specified address in the specified VLAN ID in the forwarding database
associated with this VLAN ID. associated with this VLAN ID.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment