Releases · microchip-ung/mesa

01 Apr 11:44

v2022.03

910384b

MESA-2022.03

Version:          MESA-2022.03
Previous Version: MESA-2021.12
Date:             2022-04-01
Description:      Roadmap release

General

IEC 62439-2, Media Redundancy Protocol

The MRP API has undergone a major overhaul with many non-backward compatible
changes.

LAN966x updates

Capability MESA_CAP_PACKET_INJ_ENCAP and MESA_CAP_VOP_V0 is added.

MESA_CAP_PACKET_INJ_ENCAP: Packet Tx supports injection with specific
encapsulation. This is currently only supported on LAN966x.

MESA_CAP_VOP_V0: Is used to distinguish VOP (OAM) differences between LAN966x
and Serval-1 (in earlier version both was covered by MESA_CAP_VOP_V1).

Per VLAN Ingress filtering

It is now possible to configure per VLAN ingress filtering using
mesa_vlan_vid_conf_t::ingress_filter. This feature may be used to allow
VLAN-based FRER configuration to co-exist with MSTP on platforms which do not
support the MESA_CAP_L2_MSTP_HW capability.

BSP and Toolchains

Assets 4

06 Jan 10:41

allannielsen

v2021.12

773d84a

MESA-2021.12

Version:          MESA-2021.12
Previous Version: MESA-2021.09
Date:             2022-01-06
Description:      Roadmap release

Disclaimers

General

MEPA/MESA Split

In this release, the PHY support in Unified-API/MESA has been moved to MEPA.

This includes support of the following PHYs:

Cobra: VSC8211, VSC8221
Quatro: VSC8224, VSC8244
Nano: VSC8501, VSC8502
Tesla: VSC8504, VSC8552, VSC8572, VSC8574
Atom12: VSC8512, VSC8522
Elise: VSC8514
Malibu: VSC8256, VSC8257, VSC8258
Venice: VSC8489, VSC8490, VSC8491
Viper: VSC8562, VSC8564, VSC8575, VSC8582, VSC8584
8488: VSC8487, VSC8488, VSC8487-15, VSC8488-15
Others: VSC8484, VSC8486

NOTE: LAN8814 was developed in MEPA from the beginning, and is still supported by MEPA.

In earlier releases, these PHYs were supported by the Switch API. From this
release and forward these PHYs are supported by the mepa_drv_vtss libraries
(exist in different variants).

The following has been done:

VSC PHY implementation moved from base/phy to mepa/vtss/src.
VSC PHY header files moved from include to mepa/vtss/include.
MESA PHY header files removed.
VSC PHY compile-time options:
- VTSS_OPT_PHY_1G: 1G PHYs, default included.
- VTSS_OPT_PHY_10G: 10G PHYs, default excluded.
- VTSS_OPT_PHY_TIMESTAMP: Timestamping, default excluded.
- VTSS_OPT_PHY_MACSEC: MacSec, default excluded.
- VTSS_OPT_PHY_PORT_COUNT: Port count, default 64.
- VTSS_OPT_PHY_TRACE: Trace, default included.

For switch applications, it is recommended to control the PHYs using MEBA:

MEPA drivers are installed using meba_phy_driver_init().
PHY control is then done using meba_phy_*() functions.

MEPA Free standing functions

In this release, the MEPA function pointers have been replaced by a set of
free-standing functions (see mepa/include/microchip/ethernet/phy/api/phy.h).

In earlier releases, MEPA functionality was defined and used as exemplified
below:

// Header definition
typedef mepa_rc (*mepa_driver_conf_set_t)(
    struct mepa_device *dev, const mepa_driver_conf_t *conf);

typedef struct mepa_driver {
    ...
    mepa_driver_conf_set_t             mepa_driver_conf_set;
    ...
} mepa_driver_t;

// Calling the function is done like this:
dev->drv->mepa_driver_conf_set_t(dev, &some_config);

With this change, we now have clean free standing C functions:

// Header definition
mepa_rc mepa_conf_set(struct mepa_device *dev,
                      const mepa_driver_conf_t *conf);

// Calling the function is done like this:
mepa_conf_set(dev, &some_config);

MEPA Initialization

This release changes how MEPA is initialized. The mscc_phy_driver_address_t
structure has been replaced by mepa_callout_t, and a simple mepa_create
function is now used to create MEPA instances.

The conceptual pseudo code below shows how to create MEPA instances:

typedef struct mepa_callout_cxt {
   // Add application specific stuff needed to reach the PHY registers here.
} mepa_callout_cxt_t;

// board/bsp specific content goes here
mepa_rc APPL_mmd_read(struct mepa_callout_cxt *cxt, uint8_t mmd,
                     uint16_t addr, uint16_t *const value) { return -1; }
mepa_rc APPL_mmd_read_inc(struct mepa_callout_cxt *cxt, uint8_t mmd, uint16_t addr,
                         uint16_t *const buf, uint8_t count) { return -1; }
mepa_rc APPL_mmd_write(struct mepa_callout_cxt *cxt, uint8_t mmd, uint16_t addr,
                      uint16_t value) { return -1; }
mepa_rc APPL_miim_read(struct mepa_callout_cxt *cxt, uint8_t addr,
                      uint16_t *const value) { return -1; }
mepa_rc APPL_miim_write(struct mepa_callout_cxt *cxt, uint8_t addr,
                       uint16_t value) { return -1; }

void APPL_trace_func(const mepa_trace_data_t *data, va_list args) {
   // Do filtering, and optionally add more details.
   vprintf(data->format, args);
}

void *APPL_mem_alloc(struct mepa_callout_cxt *cxt, size_t size) { return malloc(size); }
void APPL_mem_free(struct mepa_callout_cxt *cxt, void *ptr) { free(ptr); }

static mepa_callout_t APPL_mepa_callout = {
   .mepa_mmd_read = APPL_mmd_read,
   .mepa_mmd_read_inc = APPL_mmd_read_inc,
   .mepa_mmd_write = APPL_mmd_write,
   .mepa_miim_read = APPL_miim_read,
   .mepa_miim_write = APPL_miim_write,
   .mepa_mem_alloc = APPL_mem_alloc,
   .mepa_mem_free = APPL_mem_free,

   // .lock_enter   must be set if used with multi-thread
   // .lock_exit    must be set if used with multi-thread
};

static mepa_callout_cxt_t APPL_mepa_callout_cxt[APPL_PORT_CNT];
static mepa_device *APPL_mepa_devices[APPL_PORT_CNT];
void mepa_init() {
   int i;

   MEPA_TRACE_FUNCTION = APPL_trace_func;
   for (i = 0; i < APPL_PORT_CNT; ++i) {
       mepa_board_conf conf = {};
       conf.numeric_handle = i;
       APPL_fill_port_data(i, &APPL_mepa_callout_cxt[i]);
       APPL_mepa_devices[i] = mepa_create(&APPL_mepa_callout,
                                          &APPL_mepa_callout_cxt[i],
                                          &conf);
   }

   // optionally link to base port if dealing with dual/quad phy;
   for (i = 0; i < APPL_PORT_CNT; ++i) {
       if (APPL_phy_base_dev(i, &APPL_mepa_callout_cxt[i])) {
           mepa_link_base_port(APPL_mepa_devices[i],
                               APPL_phy_base_dev(i, &APPL_mepa_callout_cxt[i]),
                               APPL_phy_pkg_idx(i, &APPL_mepa_callout_cxt[i]));
       }
   }
}

MEPA time-stamping (TS) APIs added

This release adds time-stamping support in MEPA. See
mepa/include/microchip/ethernet/phy/api/phy_ts.h for details.

BSP and Toolchains

Assets 4

07 Oct 13:37

allannielsen

v2021.09

1bb814a

MESA-2021.09

Version:          MESA-2021.09
Previous Version: MESA-2021.06
Date:             2021-10-08
Description:      Roadmap release

Disclaimers

LAN9662 and LAN9668 in BETA

LAN966x (LAN9662 and LAN9668) support is included in this release, but they
are still not fully tested and should be treated as BETA quality.

LAN966x in this release can be used for early access to evaluate the features
and/or start SW integration. It is not suitable for production use.

LAN8814 (PHY) in BETA with limited support

The support of LAN8814 in this release is considered to be in BETA quality. It
can be used for early access to evaluate the features and/or start SW
integration. It is not suitable for production use.

General

This release contains a number of bugfixes for the LAN966x family, but no new
major features have been introduced.

BSP and Toolchains

Assets 4

09 Jul 08:46

allannielsen

v2021.06

bf304eb

MESA-2021.06

Version:          |MESA-2021.06
Previous Version: |MESA-2021.03
Date:             |2021-07-09
Description:      |Roadmap release

Disclaimers

LAN9662 in BETA, and LAN9668 still not supported

This is the first release introducing the two LAN9662 and LAN9668 SKUs. LAN9662
has gone through limited testing and the support of LAN9662 in this release is
considered to be in BETA quality. LAN9668 is covered in the implementation, but
it is not tested and is not considered a supported target in this release.

LAN9662 in this release can be used for early access, to evaluate the features
and/or start SW integration. It is not suitable for production use.

LAN9668 should not be used in this release.

LAN8814 (PHY) in ALPFA with limited support

This is the first release which adds MEPA (Microchip Ethernet PHY API) support
for LAN8814. The support of LAN8814 in this release is considered to be in BETA
quality. It can be used for early access, to evaluate the features and/or start
SW integration. It is not suitable for production use.

General

New port mode: `MESA_SERDES_MODE_QXGMII`

This release introduce support of MESA_SERDES_MODE_QXGMII (mode R) supporting
4x 2G5 links using a single serdes.

In the current release, only SparX-5/5i SKUs supports this mode, using either
10G or 25G serdes.

MRP Support

Media Redundancy Protocol - IEC 62439-2 HW Offload API added.

MRP is a redundancy protocol based on ring topologies. An MRP ring consists of a
manager (MRM) and a number of clients (MRC). When the ring is closed (all links
working), the manager blocks forwarding of frames between the two ring ports.
The manager sends out a periodic frame through the ring to confirm full
connectivity. If a link in the ring goes down, the manager will detect this, and
the ring is considered open. In this case, the manager will enable forwarding of
frames between the two ring ports and ask all clients to flush their MAC table.
MRP has profiles to support recovery times down to 10ms.

API also supports auto-manager where the nodes automatically determine who shall
act as manager, and it supports interconnecting multiple rings.

This feature is available if the MESA_CAP_MRP capability is set. In the
current version, this will only be the case for LAN966x SKUs.

RCL Real-Time Control lists

The RCL API is a TCAM-based feature used to classify packets for processing by
the RTE (Real-Time Engine) HW found in the LAN9662 silicon. This feature shall
be used toghether with the MERA API, and a more detailed description can be
found in the MERA-Doc.

BSP and toolchains

Assets 4

26 Mar 13:26

allannielsen

v2021.03

3efc768

MESA-2021.03

Version:          MESA-2021.03
Previous Version: MESA-2020.12
Date:             2021-03-26
Description:      Roadmap release

General

Introducing MEPA (Microchip Ethernet PHY API)

This release introduces MEPA with a basic feature set. MEPA aims at providing a
common interface for the various PHY drivers. Currently, all the PHYs supported
in MESA/Unified-API is also supported by the MEPA abstraction layer, by simply
calling into the MESA/Unified-API implementation. Future PHYs will be supported
with self-contained implementations in MEPA.

Besides the single PHY-centric support in MEPA, we also offer a board layer
of abstraction in MEBA. MEBA will take care of instantiating all the PHY
instances according to the port map and provide access functions using the port
index and forward the call to the respective MEPA driver.

The MEBA layer is optional, but highly encouraged for designs using both the
Microchip Ethernet PHYs and Switches. Users only needing the PHYs for end-node
and alternative switch-fabrics should use MEPA directly.

BSP and toolchains

Assets 4

17 Jan 19:51

allannielsen

v2020.12

8693a67

MESA-2020.12

Version:          MESA-2020.12
Previous Version: MESA-2020.09
Date:             2021-01-15
Description:      Roadmap release

General

This is a bug-fix release with no new features.

SparX-5/5i / Priority Flow Control not working

There is a known bug causing PFC not to work for SparX-5/5i. Due to this, the PFC
feature is not advertised by the capability system.

BSP and toolchains

Assets 4

01 Oct 12:00

allannielsen

v2020.09

9da743f

MESA-2020.09

Version:          MESA-2020.09
Previous Version: MESA-2020.06
Date:             2020-10-01
Description:      Roadmap release

General

SparX-5/5i (all SKUs) ready for production

Affected SKUs: VSC7546, VSC7549, VSC7552, VSC7556, VSC7558, VSC7546TSN,
VSC7549TSN, VSC7552TSN, VSC7556TSN and VSC7558TSN.

The support of SparX-5/5i (all SKUs) is considered ready for production (out of
BETA).

Third-Party PHY support added for Intel GPY211

Support for 2G5 Intel GPY211 added in the third-party PHY library. This support
is based on the Intel driver version 2.5.1, and chip ID 0x67c9dc00.

BSP and toolchains

Assets 4

03 Jul 12:36

allannielsen

v2020.06

ecb7b20

MESA-2020.06

Version:          MESA-2020.06
Previous Version: MESA-2020.03
Date:             2020-07-03
Description:      Roadmap release

Disclaimers

SparX-5/5i (all SKUs)

Affected SKUs: VSC7546, VSC7549, VSC7552, VSC7556, VSC7558, VSC7546TSN,
VSC7549TSN, VSC7552TSN, VSC7556TSN and VSC7558TSN.

The support of SparX-5/5i (all SKUs) in this release is considered to be in BETA
quality. It can be used for early access, to evaluate the features and/or start
SW integration. It is not suitable for production use.

General

10G/25G 802.3ap Backplane Ethernet (KR) has been added for SparX-5/5i (all SKUs)

This release updates the existing KR API, and with this it introduces support
for the SparX-5/5i family. The existing APIs prefixed with mesa_port_10g_kr_*
have been renamed to mesa_port_kr_*. Besides this change, a number of
additional APIs have been added to fully support SparX-5/5i.

Serval-T is regressions solved

Affected SKUs: VSC7410, VSC7415, VSC7430, VSC7435, VSC7436, VSC7437 and VSC7440

The MESA-2020.03 release had some NOR/NAND issues. These issues are now solved
in this release, and Serval-T is considered stable again.

VSC7414, VSC7416 and VSC7418 (Serval1 family) removed

The SW support of VSC7414, VSC7416 and VSC7418 has been removed in this release.

Customers who needs support for these parts needs to stay at the MESA-2020.03
release.

BSP and toolchains

Assets 4

17 Apr 13:29

allannielsen

v2020.03

94d4915

MESA-2020.03

Version:            MESA-2020.03
Previous Version:   MESA-2019.12
Date:               2020-04-17
Description:        Roadmap release

Disclaimers

Serval-T is unstable

This release has some open issues affecting the Serval-T SKUs. The issues impact traffic integrity and SPI access to NOR/NAND devices. Due to this we encourage Serval-T customer to stay on the 2019.12 release until this has been fixed.

SparX-5/5i (all SKUs)

The support of SparX-5/5i (all SKUs) in this release is considered to be in BETA quality. It can be used for early access, to evaluate the features and/or start SW integration. It is not suitable for production use.

General

This release does contain a significant amount of bug and stability fixes. Especially the SerDes settings have been improved and are much more reliable than in the MESA-2019.12 version.

Hierarchical ACLs

Support for Hierarchical ACLs has been added for SparX-5/5i products. This feature provides 6 ACLs for frame processing:

Ingress Port ACL (MESA_HACL_TYPE_IPACL)
Ingress VLAN ACL (MESA_HACL_TYPE_IVACL)
Ingress Router ACL (MESA_HACL_TYPE_IRACL)
Egress Router ACL (MESA_HACL_TYPE_ERACL)
Egress VLAN ACL (MESA_HACL_TYPE_EVACL)
Egress Port ACL (MESA_HACL_TYPE_EPACL)

The following new functions have been added in the security.h header to support this feature: mesa_hace_init, mesa_hace_add, mesa_hace_del, mesa_hace_counter_get, and mesa_hace_counter_clear.

Bug Status

Fixed:
- Queue system, status, counters (includes port macro setup).:
  - MESA-593: SparX-5: UTE: PCB134+135/Serdes10G+25G/Speed5G+10G is suffering CRC errors when using DAC cables with length different from 3m
  - MESA-594: PCB134: port: 10G SFP port speed is not changed to 1G after changing from 100FDX to 1G when 1G SX finisar SFP is inserted.
Fixed but not verified:
- None.
Known issues:
- Board API:
  - MESA-640: SparX-5/5i: Interrupts are not generated during link failure
- Queue system, status, counters (includes port macro setup).:
  - MESA-638: SparX-IV: SGMII is not supported for chip port greater than 32
  - MESA-641: Frame preemption: SparX-5i: Some of the frames are treated as CRC when Express frames load is 90% with 64 bytes framesize

Assets 4

15 Apr 12:29

allannielsen

v2019.12

09826ca

MESA-2019.12

Version:          MESA-2019.12
Previous Version: MESA-2019.09
Date:             2019-12-20
Description:      Roadmap release

Disclaimers

The support of SparX-5/5i (all SKUs) in this release is considered to be in BETA quality. It can be used for early access, to evaluate the features and/or start SW integration. It is not suitable for production use.

SparX-5/5i board support

Two reference boards exists: PCB134 and PCB135. These boards has different capabilities, and also different issues. The features and the known issues with the two boards are described below. As this is considered a BETA release, we encourage customers to use the boards, but avoid the known issues described below.

PCB134: SFP board

This board has 12x SFP+, 8x SFP28 and 1x 1G-CU PHY.

In this release, 25G support is not supported, and all the SFPs (both SFP+ and SFP28) has a max speed of 10G.

This means that the boards can demonstrate the full 200G (actually it is 201G) switching capabilities of VSC7558. If a lower grade SKU is used, only a subset of the ports will be activated.

To get the best test results, optical SFPs shall be used, or DAC cables with a length of 3 meters. Only the 10G and 1G modes are considered stable, all other modes are still in development.

PCB135: CU-PHY board

This board has 4x SFP28, 4x 10G-CU, 48x 1G-CU and 1x 1G-CU.

The support of PCB135 is still in an early state, and only the 48+1 1G CU phys are considered stable. The remaining ports has know issues, and use of these should be avoided in this release.

If the VSC7546 SKU is used, only 24x 1G ports will be available.

Time Aware Scheduler (TAS / TS) APIs added

TAS API and implementation supporting SparX-5i has been added.

A TAS configuration (mainly) consists of a cycle time and a list of gate control elements (gce). A given gate control element has a duration time specifying how long it is active, and a mask specifying which queues are open. The gate control list is repeated at every cycle time. Typically PTP is needed to synchronize the time of all the switches in the network, to ensure that the gates are managed synchronously in the network.

The TAS API can be found in the tsn.h header file, where the relevant functions are prefixed with mesa_qos_tas_.

TAS was renamed to Enhancements for Scheduled Traffic (ST) before merged into the 802.1Q-2018 standard. It goes under both names. TAS/ST was originally developed in 802.1Qbv, which is now merged into 802.1Q-2018.

ACL Extended Filtering

The ACL API now supports configurable key generation for ARP, IPv4 and IPv6 frames. This gives improved flexibility for MAC address matching for different frame types. It also provides extended IPv4/IPv6 ACL rules. This can be used for matching 128-bit IPv6 addresses for devices supporting this.

ACL CPU Disable Action

An ACL action option to actively disable copying frames to CPU has been added.

VCL QoS Actions

The VCL action has been extended with QoS related actions. It is now possible to assign both VLAN and QoS related actions to frames matching VCL rules.

TCL Priority Tagging

The TCL action now supports setting up an egress port to send priority-tagged frames for a given classified VLAN.

Enhanced VLAN API implemented for SparX-5 and SparX-5i

The enhanced VLAN API is now implemented for SparX-5 and SparX-5i targets. The API is backwards compatible with earlier chips. In SparX-5i this API is also used to support many of the TSN features.

More information can be found in the link:#mesa/docs/l2/l2[l2] section.

MESA-DOC: Examples added

In this release a section with examples has been added in MESA-DOC. Read the link:#mesa/docs/examples/introduction[introduction] section to learn more about this.

None backwards compatible changes in packet.h API

The packet.h APP has been updated with potential non-backwards compatible changes in this release. A single feature has been added, some functionality has been moved out of MESA and into the BSP, and some functions/types has been deleted because they was not relevant any more and/or because the functionality was better covered by other functions. See the detailed description in the following sub-sections.

NOTE: The changes described here also applies to the vtss_packet_api.h header.

Feature added

It is now possible to configure CPU shaping at a per queue granularity. A field called rate has been added to the mesa_packet_rx_queue_conf_t which can be used to configure a max packet rate send to the CPU on a given queue.

Feature moved to BSP

MESA used to have the following 3 functions which was required to be used, to make the packet DMA work. This design has been problematic as the actual DMA implementation is not part of MESA, it is kept in the Linux kernel (part of the BSP). In this release, these functions has been deleted from MESA, and instead added to the Linux kernel which also implements the DMA function.

mesa_packet_dma_conf_get
mesa_packet_dma_conf_set
mesa_packet_dma_offset

Application which used to call these functions shall be updated to not call them. No further workaround is needed, as BSP takes care of the configuration.

Cleaning up of functionality covered by multiple functions

A number of functions has been deleted, because the functionality they provide is better covered by other functions.

mesa_packet_rx_frame_get, mesa_packet_rx_frame_get_raw and mesa_packet_rx_frame_discard has been deleted. Instead of these functions a new functions mesa_packet_rx_frame has been added, which provides the same functionality.

mesa_packet_tx_frame_port, mesa_packet_tx_frame_port_vlan, and mesa_packet_tx_frame_vlan functions has been deleted, and the signature of mesa_packet_tx_frame has been slightly changed.

The result is 2 clean function to do register based frame RX/TX (none-DMA frame IO):

mesa_rc mesa_packet_tx_frame(
    const mesa_inst_t           inst,
    const mesa_packet_tx_info_t *const tx_info,
    const uint8_t               *const frame,
    const uint32_t              length);

mesa_rc mesa_packet_rx_frame(
    const mesa_inst_t     inst,
    uint8_t               *const data,
    const uint32_t        buflen,
    mesa_packet_rx_info_t *const rx_info);

Both functions does the IFH encoding/decoding and frame injection/extraction in one go.

Cleaning up of non-implemented functionality

The stacking related functions has been deleted as stacking is not supported for any of the chips supported by the API.

Following is the stacking related functions which has been deleted.

mesa_packet_tx_frame_vstax
mesa_packet_vstax_frame2header
mesa_packet_vstax_header2frame

The associated types are also deleted.

Assets 37

Releases: microchip-ung/mesa

MESA-2022.03

General

IEC 62439-2, Media Redundancy Protocol

LAN966x updates

Per VLAN Ingress filtering

BSP and Toolchains

MESA-2021.12

Disclaimers

General

MEPA/MESA Split

MEPA Free standing functions

MEPA Initialization

MEPA time-stamping (TS) APIs added

BSP and Toolchains

MESA-2021.09

Disclaimers

LAN9662 and LAN9668 in BETA

LAN8814 (PHY) in BETA with limited support

General

BSP and Toolchains

MESA-2021.06

Disclaimers

LAN9662 in BETA, and LAN9668 still not supported

LAN8814 (PHY) in ALPFA with limited support

General

New port mode: MESA_SERDES_MODE_QXGMII

MRP Support

RCL Real-Time Control lists

BSP and toolchains

MESA-2021.03

General

Introducing MEPA (Microchip Ethernet PHY API)

BSP and toolchains

MESA-2020.12

General

SparX-5/5i / Priority Flow Control not working

BSP and toolchains

MESA-2020.09

General

SparX-5/5i (all SKUs) ready for production

Third-Party PHY support added for Intel GPY211

BSP and toolchains

MESA-2020.06

Disclaimers

SparX-5/5i (all SKUs)

General

10G/25G 802.3ap Backplane Ethernet (KR) has been added for SparX-5/5i (all SKUs)

Serval-T is regressions solved

VSC7414, VSC7416 and VSC7418 (Serval1 family) removed

BSP and toolchains

MESA-2020.03

Disclaimers

Serval-T is unstable

SparX-5/5i (all SKUs)

General

Hierarchical ACLs

Bug Status

MESA-2019.12

Disclaimers

SparX-5/5i board support

PCB134: SFP board

PCB135: CU-PHY board

Time Aware Scheduler (TAS / TS) APIs added

ACL Extended Filtering

ACL CPU Disable Action

VCL QoS Actions

TCL Priority Tagging

Enhanced VLAN API implemented for SparX-5 and SparX-5i

MESA-DOC: Examples added

None backwards compatible changes in packet.h API

Feature added

Feature moved to BSP

Cleaning up of functionality covered by multiple functions

Cleaning up of non-implemented functionality

New port mode: `MESA_SERDES_MODE_QXGMII`