Lines Matching +full:mdio +full:- +full:connected
22 An Ethernet switch typically comprises multiple front-panel ports and one
24 presence of a management port connected to an Ethernet controller capable of
27 gateways, or even top-of-rack switches. This host Ethernet controller will
34 of multiple switches connected to each other is called a "switch tree".
36 For each front-panel port, DSA creates specialized network devices which are
37 used as controlling and data-flowing endpoints for use by the Linux networking
46 - what port is this frame coming from
47 - what was the reason why this frame got forwarded
48 - how to send CPU originated traffic to specific ports
52 on Port-based VLAN IDs).
57 - the "cpu" port is the Ethernet switch facing side of the management
61 - the "dsa" port(s) are just conduits between two or more switches, and as such
63 downstream, or the top-most upstream interface makes sense with that model
66 ------------------------
68 DSA supports many vendor-specific tagging protocols, one software-defined
69 tagging protocol, and a tag-less mode as well (``DSA_TAG_PROTO_NONE``).
74 - identifies which port the Ethernet frame came from/should be sent to
75 - provides a reason why this frame was forwarded to the management interface
82 1. The switch-specific frame header is located before the Ethernet header,
85 2. The switch-specific frame header is located before the EtherType, keeping
88 3. The switch-specific frame header is located at the tail of the packet,
102 on a best-effort basis, the allocation of packets with enough extra space such
106 Even though applications are not expected to parse DSA-specific frame headers,
118 fabric with more than one switch, the switch-specific frame header is inserted
128 by a leaf switch (not connected directly to the CPU) is not the same as what
134 EDSA tagging protocol, the operating system sees EDSA-tagged packets from the
136 because the Marvell switch connected directly to the CPU is configured to
143 tree. The DSA links are viewed as simply a pair of a DSA master (the out-facing
144 port of the upstream DSA switch) and a CPU port (the in-facing port of the
165 The passed ``struct sk_buff *skb`` has ``skb->data`` pointing at
177 passed ``struct sk_buff *skb`` has ``skb->data`` pointing at
180 method is to consume the frame header, adjust ``skb->data`` to really point at
181 the first octet after the EtherType, and to change ``skb->dev`` to point to the
182 virtual DSA user network interface corresponding to the physical front-facing
214 with DSA-unaware masters, mangling what the master perceives as MAC DA), the
218 Note that this assumes a DSA-unaware master driver, which is the norm.
221 ----------------------
233 ----------------------
238 specific (and fake) Ethernet type (later becoming ``skb->protocol``) with the
246 - receive function is invoked
247 - basic packet processing is done: getting length, status etc.
248 - packet is prepared to be processed by the Ethernet layer by calling
254 if (dev->dsa_ptr != NULL)
255 -> skb->protocol = ETH_P_XDSA
260 -> iterate over registered packet_type
261 -> invoke handler for ETH_P_XDSA, calls dsa_switch_rcv()
265 -> dsa_switch_rcv()
266 -> invoke switch tag specific protocol handler in 'net/dsa/tag_*.c'
270 - inspect and strip switch tag protocol to determine originating port
271 - locate per-port network device
272 - invoke ``eth_type_trans()`` with the DSA slave network device
273 - invoked ``netif_receive_skb()``
279 ---------------------
283 controlling and data-flowing end-point for each front-panel port of the switch.
286 - insert/remove the switch tag protocol (if it exists) when sending traffic
288 - query the switch for ethtool operations: statistics, link state,
289 Wake-on-LAN, register dumps...
290 - manage external/internal PHY: link, auto-negotiation, etc.
321 ------------------------
330 +-----------v--|--------------------+
331 |+------+ +------+ +------+ +------+|
333 |+------+-+------+-+------+-+------+|
335 +-----------------------------------+
340 +-----------------------------------+
342 --------+-----------------------------------+------------
344 +-----------------------------------+
349 +-----------------------------------+
351 |+------+ +------+ +------+ +------+|
353 ++------+-+------+-+------+-+------++
355 Slave MDIO bus
356 --------------
359 slave MDIO bus which allows a specific switch driver to divert and intercept
360 MDIO reads/writes towards specific PHY addresses. In most MDIO-connected
363 library and/or to return link status, link partner pages, auto-negotiation
366 For Ethernet switches which have both external and internal MDIO buses, the
367 slave MII bus can be utilized to mux/demux MDIO reads and writes towards either
368 internal or external MDIO devices this switch might be connected to: internal
372 ---------------
377 - ``dsa_chip_data``: platform data configuration for a given switch device,
382 - ``dsa_platform_data``: platform device configuration data which can reference
387 - ``dsa_switch_tree``: structure assigned to the master network device under
394 - ``dsa_switch``: structure describing a switch device in the tree, referencing
398 - ``dsa_switch_ops``: structure referencing function pointers, see below for a
405 -------------------------------
410 - inability to fetch switch CPU port statistics counters using ethtool, which
411 can make it harder to debug MDIO switch connected using xMII interfaces
413 - inability to configure the CPU port link parameters based on the Ethernet
416 - inability to configure specific VLAN IDs / trunking VLANs between switches
420 --------------------------------
422 Once a master network device is configured to use DSA (dev->dsa_ptr becomes
423 non-NULL), and the switch behind it expects a tagging protocol, this network
435 - MDIO/PHY library: ``drivers/net/phy/phy.c``, ``mdio_bus.c``
436 - Switchdev:``net/switchdev/*``
437 - Device Tree for various of_* functions
438 - Devlink: ``net/core/devlink.c``
440 MDIO/PHY library
441 ----------------
447 - internal PHY devices, built into the Ethernet switch hardware
448 - external PHY devices, connected via an internal or external MDIO bus
449 - internal PHY devices, connected via an internal MDIO bus
450 - special, non-autonegotiated or non MDIO-managed PHY devices: SFPs, MoCA; a.k.a
456 - if Device Tree is used, the PHY device is looked up using the standard
457 "phy-handle" property, if found, this PHY device is created and registered
460 - if Device Tree is used and the PHY device is "fixed", that is, conforms to
461 the definition of a non-MDIO managed PHY as defined in
462 ``Documentation/devicetree/bindings/net/fixed-link.txt``, the PHY is registered
463 and connected transparently using the special fixed MDIO bus driver
465 - finally, if the PHY is built into the switch, as is very common with
471 ---------
475 of per-port slave network devices. As of today, the only SWITCHDEV objects
479 -------
487 - Regions: debugging feature which allows user space to dump driver-defined
488 areas of hardware information in a low-level, binary format. Both global
489 regions as well as per-port regions are supported. It is possible to export
491 to the standard iproute2 user space programs (ip-link, bridge), like address
493 contain additional hardware-specific details which are not visible through
495 the non-user ports too, which are invisible to iproute2 because no network
497 - Params: a feature which enables user to configure certain low-level tunable
499 devlink params, or may add new device-specific devlink params.
500 - Resources: a monitoring feature which enables users to see the degree of
502 - Shared buffers: a QoS feature for adjusting and partitioning memory and frame
504 directions, such that low-priority bulk traffic does not impede the
505 processing of high-priority critical traffic.
510 -----------
513 ``Documentation/devicetree/bindings/net/dsa/dsa.txt``. PHY/MDIO library helper
515 per-port PHY specific details: interface connection, MDIO bus location, etc.
524 -----------------------------------------
527 I2C, MDIO or otherwise). The DSA framework is not involved in their probing
535 - ``ds->dev``: will be used to parse the switch's OF node or platform data.
537 - ``ds->num_ports``: will be used to create the port list for this switch, and
540 - ``ds->ops``: a pointer to the ``dsa_switch_ops`` structure holding the DSA
543 - ``ds->priv``: backpointer to a driver-private data structure which can be
547 be configured to obtain driver-specific behavior from the DSA core. Their
550 - ``ds->vlan_filtering_is_global``
552 - ``ds->needs_standalone_vlan_filtering``
554 - ``ds->configure_vlan_while_not_filtering``
556 - ``ds->untag_bridge_pvid``
558 - ``ds->assisted_learning_on_cpu_port``
560 - ``ds->mtu_enforcement_ingress``
562 - ``ds->fdb_isolation``
574 The first N-1 callers of ``dsa_register_switch()`` only add their ports to the
575 port list of the tree (``dst->ports``), each port having a backpointer to its
576 associated switch (``dp->ds``). Then, these switches exit their
581 continuation of initialization (including the call to ``ds->ops->setup()``) for
608 --------------------
610 - ``get_tag_protocol``: this is to indicate what kind of tagging protocol is
617 - ``change_tag_protocol``: when the default tagging protocol has compatibility
623 - ``setup``: setup function for the switch, this function is responsible for setting
628 a Port-based VLAN ID for each port and allowing only the CPU port and the
637 - ``port_setup`` and ``port_teardown``: methods for initialization and
638 destruction of per-port data structures. It is mandatory for some operations
646 - ``port_change_master``: method through which the affinity (association used
655 master->dsa_ptr``. Additionally, the master can also be a LAG device where
657 valid ``master->dsa_ptr`` pointer, however this is not unique, but rather a
665 -------------------------------
667 - ``get_phy_flags``: Some switches are interfaced to various kinds of Ethernet PHYs,
670 should return a 32-bit bitmask of "flags" that is private between the switch
673 - ``phy_read``: Function invoked by the DSA slave MDIO bus when attempting to read
674 the switch port MDIO registers. If unavailable, return 0xffff for each read.
676 status, auto-negotiation results, link partner pages, etc.
678 - ``phy_write``: Function invoked by the DSA slave MDIO bus when attempting to write
679 to the switch port MDIO registers. If unavailable return a negative error
682 - ``adjust_link``: Function invoked by the PHY library when a slave network device
687 - ``fixed_link_update``: Function invoked by the PHY library, and specifically by
689 not be auto-negotiated, or obtained by reading the PHY registers through MDIO.
691 MoCA or other kinds of non-MDIO managed PHYs where out of band link
695 ------------------
697 - ``get_strings``: ethtool function used to query the driver's strings, will
700 - ``get_ethtool_stats``: ethtool function used to query per-port statistics and
705 - ``get_sset_count``: ethtool function used to query the number of statistics items
707 - ``get_wol``: ethtool function used to obtain Wake-on-LAN settings per-port, this
709 Wake-on-LAN settings if this interface needs to participate in Wake-on-LAN
711 - ``set_wol``: ethtool function used to configure Wake-on-LAN settings per-port,
714 - ``set_eee``: ethtool function which is used to configure a switch port EEE (Green
717 controller and data-processing logic
719 - ``get_eee``: ethtool function which is used to query a switch port EEE settings,
721 and data-processing logic as well as query the PHY for its currently configured
724 - ``get_eeprom_len``: ethtool function returning for a given switch the EEPROM
727 - ``get_eeprom``: ethtool function returning for a given switch the EEPROM contents
729 - ``set_eeprom``: ethtool function writing specified data to a given switch EEPROM
731 - ``get_regs_len``: ethtool function returning the register length for a given
734 - ``get_regs``: ethtool function returning the Ethernet switch internal register
735 contents. This function might require user-land code in ethtool to
736 pretty-print register values and registers
739 ----------------
741 - ``suspend``: function invoked by the DSA platform device when the system goes to
743 participating in Wake-on-LAN active as well as additional wake-up logic if
746 - ``resume``: function invoked by the DSA platform device when the system resumes,
747 should resume all Ethernet switch activities and re-configure the switch to be
750 - ``port_enable``: function invoked by the DSA slave network device ndo_open
756 - ``port_disable``: function invoked by the DSA slave network device ndo_close
763 -----------------
772 For example, all ports that belong to a VLAN-unaware bridge (which is
773 *currently* VLAN-unaware) are expected to learn source addresses in the
775 VLAN-unaware bridges). During forwarding and FDB lookup, a packet received on a
776 VLAN-unaware bridge port should be able to find a VLAN-unaware FDB entry having
780 a port which is a member of a different VLAN-unaware bridge (and is therefore
783 Similarly, each VLAN of each offloaded VLAN-aware bridge should have an
788 In this context, a VLAN-unaware database means that all packets are expected to
790 VLAN-aware database means that packets are supposed to match based on the VLAN
793 At the bridge layer, VLAN-unaware FDB entries have the special VID value of 0,
794 whereas VLAN-aware FDB entries have non-zero VID values. Note that a
795 VLAN-unaware bridge may have VLAN-aware (non-zero VID) FDB entries, and a
796 VLAN-aware bridge may have VLAN-unaware FDB entries. As in hardware, the
828 - Primary unicast MAC addresses of ports (``dev->dev_addr``). These are
833 - Secondary unicast and multicast MAC addresses of ports (addresses added
837 - Local/permanent bridge FDB entries (``BR_FDB_LOCAL``). These are the MAC
842 - Static bridge FDB entries installed towards foreign (non-DSA) interfaces
846 - Dynamically learned FDB entries on foreign interfaces present in the same
847 bridge as some DSA switch ports, only if ``ds->assisted_learning_on_cpu_port``
854 - ``DSA_DB_PORT``: the FDB (or MDB) entry to be installed or deleted belongs to
855 the port private database of user port ``db->dp``.
856 - ``DSA_DB_BRIDGE``: the entry belongs to one of the address databases of bridge
857 ``db->bridge``. Separation between the VLAN-unaware database and the per-VID
859 - ``DSA_DB_LAG``: the entry belongs to the address database of LAG ``db->lag``.
863 ``port_mdb_add`` etc should declare ``ds->fdb_isolation`` as true.
865 DSA associates each offloaded bridge and each offloaded LAG with a one-based ID
868 scheme (the ID is readable through ``db->bridge.num`` and ``db->lag.id`` or may
874 drivers even if they do not support FDB isolation. However, ``db->bridge.num``
875 and ``db->lag.id`` are always set to 0 in that case (to denote the lack of
882 share the same database, but the reference counting of host-filtered addresses
893 ------------
896 below. They may be absent, return -EOPNOTSUPP, or ``ds->max_num_bridges`` may
897 be non-zero and exceeded, and in this case, joining a bridge port is still
922 packets and have ``skb->offload_fwd_mark`` set to true in the tag protocol
932 VLAN-unaware, and in this case the FID must be equal to the FID used by the
933 driver for its VLAN-unaware address database associated with that bridge.
934 Alternatively, the bridge may be VLAN-aware, and in that case, it is guaranteed
935 that the packet is also VLAN-tagged with the VLAN ID that the bridge processed
937 the egress-untagged ports, or keep the tag on the egress-tagged ones.
939 - ``port_bridge_join``: bridge layer function invoked when a given switch port is
946 - ``port_bridge_leave``: bridge layer function invoked when a given switch port is
951 - ``port_stp_state_set``: bridge layer function invoked when a given switch port STP
955 - ``port_bridge_flags``: bridge layer function invoked when a port must
966 - ``port_fast_age``: bridge layer function invoked when flushing the
973 ---------------------
975 - ``port_vlan_filtering``: bridge layer function invoked when the bridge gets
985 - ``port_vlan_add``: bridge layer function invoked when a VLAN is configured
994 - ``port_vlan_del``: bridge layer function invoked when a VLAN is removed from the
997 - ``port_fdb_add``: bridge layer function invoked when the bridge wants to install a
1002 - ``port_fdb_del``: bridge layer function invoked when the bridge wants to remove a
1007 - ``port_fdb_dump``: bridge bypass function invoked by ``ndo_fdb_dump`` on the
1014 - ``port_mdb_add``: bridge layer function invoked when the bridge wants to install
1019 - ``port_mdb_del``: bridge layer function invoked when the bridge wants to remove a
1025 ----------------
1042 - ``port_lag_join``: function invoked when a given switch port is added to a
1043 LAG. The driver may return ``-EOPNOTSUPP``, and in this case, DSA will fall
1046 - ``port_lag_leave``: function invoked when a given switch port leaves a LAG
1048 - ``port_lag_change``: function invoked when the link state of any member of
1053 can optionally populate ``ds->num_lag_ids`` from the ``dsa_switch_ops::setup``
1057 IEC 62439-2 (MRP)
1058 -----------------
1073 necessary for the hardware, even if it is not MRP-aware, to be able to extract
1075 implementation. DSA today has no driver which is MRP-aware, therefore it only
1079 - ``port_mrp_add`` and ``port_mrp_del``: notifies driver when an MRP instance
1082 - ``port_mrp_add_ring_role`` and ``port_mrp_del_ring_role``: function invoked
1087 IEC 62439-3 (HSR/PRP)
1088 ---------------------
1093 eliminating the duplicates at the receiver. The High-availability Seamless
1095 the redundant traffic are aware of the fact that it is HSR-tagged (because HSR
1096 uses a header with an EtherType of 0x892f) and are physically connected in a
1109 ``Documentation/networking/netdev-features.rst``. Additionally, the following
1112 - ``port_hsr_join``: function invoked when a given switch port is added to a
1113 DANP/DANH. The driver may return ``-EOPNOTSUPP`` and in this case, DSA will
1116 - ``port_hsr_leave``: function invoked when a given switch port leaves a
1123 -------------------------------------------------------------