Lines Matching +full:mv88e6xxx +full:- +full:mdio +full:- +full:external
14 support Marvell Ethernet switches (MV88E6xxx, a.k.a. Link Street product
22 An Ethernet switch typically comprises multiple front-panel ports and one
27 gateways, or even top-of-rack switches. This host Ethernet controller will
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
70 ------------------------
72 DSA supports many vendor-specific tagging protocols, one software-defined
73 tagging protocol, and a tag-less mode as well (``DSA_TAG_PROTO_NONE``).
78 - identifies which port the Ethernet frame came from/should be sent to
79 - provides a reason why this frame was forwarded to the management interface
86 1. The switch-specific frame header is located before the Ethernet header,
89 2. The switch-specific frame header is located before the EtherType, keeping
92 3. The switch-specific frame header is located at the tail of the packet,
106 on a best-effort basis, the allocation of packets with enough extra space such
110 Even though applications are not expected to parse DSA-specific frame headers,
122 fabric with more than one switch, the switch-specific frame header is inserted
138 EDSA tagging protocol, the operating system sees EDSA-tagged packets from the
147 tree. The DSA links are viewed as simply a pair of a DSA conduit (the out-facing
148 port of the upstream DSA switch) and a CPU port (the in-facing port of the
169 The passed ``struct sk_buff *skb`` has ``skb->data`` pointing at
181 passed ``struct sk_buff *skb`` has ``skb->data`` pointing at
184 method is to consume the frame header, adjust ``skb->data`` to really point at
185 the first octet after the EtherType, and to change ``skb->dev`` to point to the
186 virtual DSA user network interface corresponding to the physical front-facing
218 with DSA-unaware conduits, mangling what the conduit perceives as MAC DA), the
222 Note that this assumes a DSA-unaware conduit driver, which is the norm.
225 -----------------------
237 ----------------------
242 specific (and fake) Ethernet type (later becoming ``skb->protocol``) with the
250 - receive function is invoked
251 - basic packet processing is done: getting length, status etc.
252 - packet is prepared to be processed by the Ethernet layer by calling
258 if (dev->dsa_ptr != NULL)
259 -> skb->protocol = ETH_P_XDSA
264 -> iterate over registered packet_type
265 -> invoke handler for ETH_P_XDSA, calls dsa_switch_rcv()
269 -> dsa_switch_rcv()
270 -> invoke switch tag specific protocol handler in 'net/dsa/tag_*.c'
274 - inspect and strip switch tag protocol to determine originating port
275 - locate per-port network device
276 - invoke ``eth_type_trans()`` with the DSA user network device
277 - invoked ``netif_receive_skb()``
283 --------------------
287 controlling and data-flowing end-point for each front-panel port of the switch.
290 - insert/remove the switch tag protocol (if it exists) when sending traffic
292 - query the switch for ethtool operations: statistics, link state,
293 Wake-on-LAN, register dumps...
294 - manage external/internal PHY: link, auto-negotiation, etc.
325 ------------------------
334 +-----------v--|--------------------+
335 |+------+ +------+ +------+ +------+|
337 |+------+-+------+-+------+-+------+|
339 +-----------------------------------+
344 +-----------------------------------+
346 --------+-----------------------------------+------------
348 +-----------------------------------+
353 +-----------------------------------+
355 |+------+ +------+ +------+ +------+|
357 ++------+-+------+-+------+-+------++
359 User MDIO bus
360 -------------
363 user MDIO bus which allows a specific switch driver to divert and intercept
364 MDIO reads/writes towards specific PHY addresses. In most MDIO-connected
367 library and/or to return link status, link partner pages, auto-negotiation
370 For Ethernet switches which have both external and internal MDIO buses, the
371 user MII bus can be utilized to mux/demux MDIO reads and writes towards either
372 internal or external MDIO devices this switch might be connected to: internal
373 PHYs, external PHYs, or even external switches.
376 ---------------
381 - ``dsa_chip_data``: platform data configuration for a given switch device,
386 - ``dsa_platform_data``: platform device configuration data which can reference
391 - ``dsa_switch_tree``: structure assigned to the conduit network device under
398 - ``dsa_switch``: structure describing a switch device in the tree, referencing
402 - ``dsa_switch_ops``: structure referencing function pointers, see below for a
409 -------------------------------
414 - inability to fetch switch CPU port statistics counters using ethtool, which
415 can make it harder to debug MDIO switch connected using xMII interfaces
417 - inability to configure the CPU port link parameters based on the Ethernet
420 - inability to configure specific VLAN IDs / trunking VLANs between switches
424 --------------------------------
426 Once a conduit network device is configured to use DSA (dev->dsa_ptr becomes
427 non-NULL), and the switch behind it expects a tagging protocol, this network
439 - MDIO/PHY library: ``drivers/net/phy/phy.c``, ``mdio_bus.c``
440 - Switchdev:``net/switchdev/*``
441 - Device Tree for various of_* functions
442 - Devlink: ``net/core/devlink.c``
444 MDIO/PHY library
445 ----------------
451 - internal PHY devices, built into the Ethernet switch hardware
452 - external PHY devices, connected via an internal or external MDIO bus
453 - internal PHY devices, connected via an internal MDIO bus
454 - special, non-autonegotiated or non MDIO-managed PHY devices: SFPs, MoCA; a.k.a
460 - if Device Tree is used, the PHY device is looked up using the standard
461 "phy-handle" property, if found, this PHY device is created and registered
464 - if Device Tree is used and the PHY device is "fixed", that is, conforms to
465 the definition of a non-MDIO managed PHY as defined in
466 ``Documentation/devicetree/bindings/net/fixed-link.txt``, the PHY is registered
467 and connected transparently using the special fixed MDIO bus driver
469 - finally, if the PHY is built into the switch, as is very common with
475 ---------
479 of per-port user network devices. As of today, the only SWITCHDEV objects
483 -------
491 - Regions: debugging feature which allows user space to dump driver-defined
492 areas of hardware information in a low-level, binary format. Both global
493 regions as well as per-port regions are supported. It is possible to export
495 to the standard iproute2 user space programs (ip-link, bridge), like address
497 contain additional hardware-specific details which are not visible through
499 the non-user ports too, which are invisible to iproute2 because no network
501 - Params: a feature which enables user to configure certain low-level tunable
503 devlink params, or may add new device-specific devlink params.
504 - Resources: a monitoring feature which enables users to see the degree of
506 - Shared buffers: a QoS feature for adjusting and partitioning memory and frame
508 directions, such that low-priority bulk traffic does not impede the
509 processing of high-priority critical traffic.
514 -----------
517 ``Documentation/devicetree/bindings/net/dsa/dsa.txt``. PHY/MDIO library helper
519 per-port PHY specific details: interface connection, MDIO bus location, etc.
528 -----------------------------------------
531 I2C, MDIO or otherwise). The DSA framework is not involved in their probing
539 - ``ds->dev``: will be used to parse the switch's OF node or platform data.
541 - ``ds->num_ports``: will be used to create the port list for this switch, and
544 - ``ds->ops``: a pointer to the ``dsa_switch_ops`` structure holding the DSA
547 - ``ds->priv``: backpointer to a driver-private data structure which can be
551 be configured to obtain driver-specific behavior from the DSA core. Their
554 - ``ds->vlan_filtering_is_global``
556 - ``ds->needs_standalone_vlan_filtering``
558 - ``ds->configure_vlan_while_not_filtering``
560 - ``ds->untag_bridge_pvid``
562 - ``ds->assisted_learning_on_cpu_port``
564 - ``ds->mtu_enforcement_ingress``
566 - ``ds->fdb_isolation``
578 The first N-1 callers of ``dsa_register_switch()`` only add their ports to the
579 port list of the tree (``dst->ports``), each port having a backpointer to its
580 associated switch (``dp->ds``). Then, these switches exit their
585 continuation of initialization (including the call to ``ds->ops->setup()``) for
612 --------------------
614 - ``get_tag_protocol``: this is to indicate what kind of tagging protocol is
621 - ``change_tag_protocol``: when the default tagging protocol has compatibility
627 - ``setup``: setup function for the switch, this function is responsible for setting
632 a Port-based VLAN ID for each port and allowing only the CPU port and the
641 - ``port_setup`` and ``port_teardown``: methods for initialization and
642 destruction of per-port data structures. It is mandatory for some operations
650 - ``port_change_conduit``: method through which the affinity (association used
659 conduit->dsa_ptr``. Additionally, the conduit can also be a LAG device where
661 valid ``conduit->dsa_ptr`` pointer, however this is not unique, but rather a
669 -------------------------------
671 - ``get_phy_flags``: Some switches are interfaced to various kinds of Ethernet PHYs,
674 should return a 32-bit bitmask of "flags" that is private between the switch
677 - ``phy_read``: Function invoked by the DSA user MDIO bus when attempting to read
678 the switch port MDIO registers. If unavailable, return 0xffff for each read.
680 status, auto-negotiation results, link partner pages, etc.
682 - ``phy_write``: Function invoked by the DSA user MDIO bus when attempting to write
683 to the switch port MDIO registers. If unavailable return a negative error
686 - ``adjust_link``: Function invoked by the PHY library when a user network device
691 - ``fixed_link_update``: Function invoked by the PHY library, and specifically by
693 not be auto-negotiated, or obtained by reading the PHY registers through MDIO.
695 MoCA or other kinds of non-MDIO managed PHYs where out of band link
699 ------------------
701 - ``get_strings``: ethtool function used to query the driver's strings, will
704 - ``get_ethtool_stats``: ethtool function used to query per-port statistics and
709 - ``get_sset_count``: ethtool function used to query the number of statistics items
711 - ``get_wol``: ethtool function used to obtain Wake-on-LAN settings per-port, this
713 Wake-on-LAN settings if this interface needs to participate in Wake-on-LAN
715 - ``set_wol``: ethtool function used to configure Wake-on-LAN settings per-port,
718 - ``set_eee``: ethtool function which is used to configure a switch port EEE (Green
721 controller and data-processing logic
723 - ``get_eee``: ethtool function which is used to query a switch port EEE settings,
725 and data-processing logic as well as query the PHY for its currently configured
728 - ``get_eeprom_len``: ethtool function returning for a given switch the EEPROM
731 - ``get_eeprom``: ethtool function returning for a given switch the EEPROM contents
733 - ``set_eeprom``: ethtool function writing specified data to a given switch EEPROM
735 - ``get_regs_len``: ethtool function returning the register length for a given
738 - ``get_regs``: ethtool function returning the Ethernet switch internal register
739 contents. This function might require user-land code in ethtool to
740 pretty-print register values and registers
743 ----------------
745 - ``suspend``: function invoked by the DSA platform device when the system goes to
747 participating in Wake-on-LAN active as well as additional wake-up logic if
750 - ``resume``: function invoked by the DSA platform device when the system resumes,
751 should resume all Ethernet switch activities and re-configure the switch to be
754 - ``port_enable``: function invoked by the DSA user network device ndo_open
760 - ``port_disable``: function invoked by the DSA user network device ndo_close
767 -----------------
776 For example, all ports that belong to a VLAN-unaware bridge (which is
777 *currently* VLAN-unaware) are expected to learn source addresses in the
779 VLAN-unaware bridges). During forwarding and FDB lookup, a packet received on a
780 VLAN-unaware bridge port should be able to find a VLAN-unaware FDB entry having
784 a port which is a member of a different VLAN-unaware bridge (and is therefore
787 Similarly, each VLAN of each offloaded VLAN-aware bridge should have an
792 In this context, a VLAN-unaware database means that all packets are expected to
794 VLAN-aware database means that packets are supposed to match based on the VLAN
797 At the bridge layer, VLAN-unaware FDB entries have the special VID value of 0,
798 whereas VLAN-aware FDB entries have non-zero VID values. Note that a
799 VLAN-unaware bridge may have VLAN-aware (non-zero VID) FDB entries, and a
800 VLAN-aware bridge may have VLAN-unaware FDB entries. As in hardware, the
832 - Primary unicast MAC addresses of ports (``dev->dev_addr``). These are
837 - Secondary unicast and multicast MAC addresses of ports (addresses added
841 - Local/permanent bridge FDB entries (``BR_FDB_LOCAL``). These are the MAC
846 - Static bridge FDB entries installed towards foreign (non-DSA) interfaces
850 - Dynamically learned FDB entries on foreign interfaces present in the same
851 bridge as some DSA switch ports, only if ``ds->assisted_learning_on_cpu_port``
858 - ``DSA_DB_PORT``: the FDB (or MDB) entry to be installed or deleted belongs to
859 the port private database of user port ``db->dp``.
860 - ``DSA_DB_BRIDGE``: the entry belongs to one of the address databases of bridge
861 ``db->bridge``. Separation between the VLAN-unaware database and the per-VID
863 - ``DSA_DB_LAG``: the entry belongs to the address database of LAG ``db->lag``.
867 ``port_mdb_add`` etc should declare ``ds->fdb_isolation`` as true.
869 DSA associates each offloaded bridge and each offloaded LAG with a one-based ID
872 scheme (the ID is readable through ``db->bridge.num`` and ``db->lag.id`` or may
878 drivers even if they do not support FDB isolation. However, ``db->bridge.num``
879 and ``db->lag.id`` are always set to 0 in that case (to denote the lack of
886 share the same database, but the reference counting of host-filtered addresses
897 ------------
900 below. They may be absent, return -EOPNOTSUPP, or ``ds->max_num_bridges`` may
901 be non-zero and exceeded, and in this case, joining a bridge port is still
926 packets and have ``skb->offload_fwd_mark`` set to true in the tag protocol
936 VLAN-unaware, and in this case the FID must be equal to the FID used by the
937 driver for its VLAN-unaware address database associated with that bridge.
938 Alternatively, the bridge may be VLAN-aware, and in that case, it is guaranteed
939 that the packet is also VLAN-tagged with the VLAN ID that the bridge processed
941 the egress-untagged ports, or keep the tag on the egress-tagged ones.
943 - ``port_bridge_join``: bridge layer function invoked when a given switch port is
950 - ``port_bridge_leave``: bridge layer function invoked when a given switch port is
955 - ``port_stp_state_set``: bridge layer function invoked when a given switch port STP
959 - ``port_bridge_flags``: bridge layer function invoked when a port must
970 - ``port_fast_age``: bridge layer function invoked when flushing the
977 ---------------------
979 - ``port_vlan_filtering``: bridge layer function invoked when the bridge gets
989 - ``port_vlan_add``: bridge layer function invoked when a VLAN is configured
998 - ``port_vlan_del``: bridge layer function invoked when a VLAN is removed from the
1001 - ``port_fdb_add``: bridge layer function invoked when the bridge wants to install a
1006 - ``port_fdb_del``: bridge layer function invoked when the bridge wants to remove a
1011 - ``port_fdb_dump``: bridge bypass function invoked by ``ndo_fdb_dump`` on the
1018 - ``port_mdb_add``: bridge layer function invoked when the bridge wants to install
1023 - ``port_mdb_del``: bridge layer function invoked when the bridge wants to remove a
1029 ----------------
1046 - ``port_lag_join``: function invoked when a given switch port is added to a
1047 LAG. The driver may return ``-EOPNOTSUPP``, and in this case, DSA will fall
1050 - ``port_lag_leave``: function invoked when a given switch port leaves a LAG
1052 - ``port_lag_change``: function invoked when the link state of any member of
1057 can optionally populate ``ds->num_lag_ids`` from the ``dsa_switch_ops::setup``
1061 IEC 62439-2 (MRP)
1062 -----------------
1077 necessary for the hardware, even if it is not MRP-aware, to be able to extract
1079 implementation. DSA today has no driver which is MRP-aware, therefore it only
1083 - ``port_mrp_add`` and ``port_mrp_del``: notifies driver when an MRP instance
1086 - ``port_mrp_add_ring_role`` and ``port_mrp_del_ring_role``: function invoked
1091 IEC 62439-3 (HSR/PRP)
1092 ---------------------
1097 eliminating the duplicates at the receiver. The High-availability Seamless
1099 the redundant traffic are aware of the fact that it is HSR-tagged (because HSR
1113 ``Documentation/networking/netdev-features.rst``. Additionally, the following
1116 - ``port_hsr_join``: function invoked when a given switch port is added to a
1117 DANP/DANH. The driver may return ``-EOPNOTSUPP`` and in this case, DSA will
1120 - ``port_hsr_leave``: function invoked when a given switch port leaves a
1127 -------------------------------------------------------------