From: Daniel Golle Date: Tue, 23 Apr 2024 12:08:02 +0000 (+0100) Subject: generic: mt7530: move accepted patches to backport-6.{1,6} X-Git-Url: http://git.lede-project.org./?a=commitdiff_plain;h=70853560f83af2786ed1884e5db8e4214d58e8cf;p=openwrt%2Fstaging%2Fblogic.git generic: mt7530: move accepted patches to backport-6.{1,6} Move two accepted patches for the MT7530 DSA driver from pending-6.{1,6} to backport-6.{1,6}. Signed-off-by: Daniel Golle --- diff --git a/target/linux/generic/backport-6.1/790-47-v6.10-net-dsa-mt7530-fix-enabling-EEE-on-MT7531-switch-on-.patch b/target/linux/generic/backport-6.1/790-47-v6.10-net-dsa-mt7530-fix-enabling-EEE-on-MT7531-switch-on-.patch new file mode 100644 index 000000000000..dc202a55e69d --- /dev/null +++ b/target/linux/generic/backport-6.1/790-47-v6.10-net-dsa-mt7530-fix-enabling-EEE-on-MT7531-switch-on-.patch @@ -0,0 +1,92 @@ +From ef972fc9f5743da589ce9546dd565d6c56e679b8 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ar=C4=B1n=C3=A7=20=C3=9CNAL?= +Date: Mon, 8 Apr 2024 10:08:53 +0300 +Subject: [PATCH 1/2] net: dsa: mt7530: fix enabling EEE on MT7531 switch on + all boards +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +The commit 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE features") +brought EEE support but did not enable EEE on MT7531 switch MACs. EEE is +enabled on MT7531 switch MACs by pulling the LAN2LED0 pin low on the board +(bootstrapping), unsetting the EEE_DIS bit on the trap register, or setting +the internal EEE switch bit on the CORE_PLL_GROUP4 register. Thanks to +SkyLake Huang (黃啟澤) from MediaTek for providing information on the +internal EEE switch bit. + +There are existing boards that were not designed to pull the pin low. +Because of that, the EEE status currently depends on the board design. + +The EEE_DIS bit on the trap pertains to the LAN2LED0 pin which is usually +used to control an LED. Once the bit is unset, the pin will be low. That +will make the active low LED turn on. The pin is controlled by the switch +PHY. It seems that the PHY controls the pin in the way that it inverts the +pin state. That means depending on the wiring of the LED connected to +LAN2LED0 on the board, the LED may be on without an active link. + +To not cause this unwanted behaviour whilst enabling EEE on all boards, set +the internal EEE switch bit on the CORE_PLL_GROUP4 register. + +My testing on MT7531 shows a certain amount of traffic loss when EEE is +enabled. That said, I haven't come across a board that enables EEE. So +enable EEE on the switch MACs but disable EEE advertisement on the switch +PHYs. This way, we don't change the behaviour of the majority of the boards +that have this switch. The mediatek-ge PHY driver already disables EEE +advertisement on the switch PHYs but my testing shows that it is somehow +enabled afterwards. Disabling EEE advertisement before the PHY driver +initialises keeps it off. + +With this change, EEE can now be enabled using ethtool. + +Fixes: 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE features") +Reviewed-by: Florian Fainelli +Signed-off-by: Arınç ÜNAL +--- + drivers/net/dsa/mt7530.c | 17 ++++++++++++----- + drivers/net/dsa/mt7530.h | 1 + + 2 files changed, 13 insertions(+), 5 deletions(-) + +--- a/drivers/net/dsa/mt7530.c ++++ b/drivers/net/dsa/mt7530.c +@@ -2496,18 +2496,25 @@ mt7531_setup(struct dsa_switch *ds) + mt7530_rmw(priv, MT7531_GPIO_MODE0, MT7531_GPIO0_MASK, + MT7531_GPIO0_INTERRUPT); + +- /* Enable PHY core PLL, since phy_device has not yet been created +- * provided for phy_[read,write]_mmd_indirect is called, we provide +- * our own mt7531_ind_mmd_phy_[read,write] to complete this +- * function. ++ /* Enable Energy-Efficient Ethernet (EEE) and PHY core PLL, since ++ * phy_device has not yet been created provided for ++ * phy_[read,write]_mmd_indirect is called, we provide our own ++ * mt7531_ind_mmd_phy_[read,write] to complete this function. + */ + val = mt7531_ind_c45_phy_read(priv, MT753X_CTRL_PHY_ADDR, + MDIO_MMD_VEND2, CORE_PLL_GROUP4); +- val |= MT7531_PHY_PLL_BYPASS_MODE; ++ val |= MT7531_RG_SYSPLL_DMY2 | MT7531_PHY_PLL_BYPASS_MODE; + val &= ~MT7531_PHY_PLL_OFF; + mt7531_ind_c45_phy_write(priv, MT753X_CTRL_PHY_ADDR, MDIO_MMD_VEND2, + CORE_PLL_GROUP4, val); + ++ /* Disable EEE advertisement on the switch PHYs. */ ++ for (i = MT753X_CTRL_PHY_ADDR; ++ i < MT753X_CTRL_PHY_ADDR + MT7530_NUM_PHYS; i++) { ++ mt7531_ind_c45_phy_write(priv, i, MDIO_MMD_AN, MDIO_AN_EEE_ADV, ++ 0); ++ } ++ + mt7531_setup_common(ds); + + /* Setup VLAN ID 0 for VLAN-unaware bridges */ +--- a/drivers/net/dsa/mt7530.h ++++ b/drivers/net/dsa/mt7530.h +@@ -616,6 +616,7 @@ enum mt7531_clk_skew { + #define RG_SYSPLL_DDSFBK_EN BIT(12) + #define RG_SYSPLL_BIAS_EN BIT(11) + #define RG_SYSPLL_BIAS_LPF_EN BIT(10) ++#define MT7531_RG_SYSPLL_DMY2 BIT(6) + #define MT7531_PHY_PLL_OFF BIT(5) + #define MT7531_PHY_PLL_BYPASS_MODE BIT(4) + diff --git a/target/linux/generic/backport-6.1/790-48-STABLE-net-dsa-mt7530-trap-link-local-frames-regardless-of-.patch b/target/linux/generic/backport-6.1/790-48-STABLE-net-dsa-mt7530-trap-link-local-frames-regardless-of-.patch new file mode 100644 index 000000000000..4d70e774a4d5 --- /dev/null +++ b/target/linux/generic/backport-6.1/790-48-STABLE-net-dsa-mt7530-trap-link-local-frames-regardless-of-.patch @@ -0,0 +1,483 @@ +From b7427d66cb3d6dca5165de5f7d80d59f08c2795b Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ar=C4=B1n=C3=A7=20=C3=9CNAL?= +Date: Tue, 9 Apr 2024 18:01:14 +0300 +Subject: [PATCH 2/2] net: dsa: mt7530: trap link-local frames regardless of ST + Port State +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +In Clause 5 of IEEE Std 802-2014, two sublayers of the data link layer +(DLL) of the Open Systems Interconnection basic reference model (OSI/RM) +are described; the medium access control (MAC) and logical link control +(LLC) sublayers. The MAC sublayer is the one facing the physical layer. + +In 8.2 of IEEE Std 802.1Q-2022, the Bridge architecture is described. A +Bridge component comprises a MAC Relay Entity for interconnecting the Ports +of the Bridge, at least two Ports, and higher layer entities with at least +a Spanning Tree Protocol Entity included. + +Each Bridge Port also functions as an end station and shall provide the MAC +Service to an LLC Entity. Each instance of the MAC Service is provided to a +distinct LLC Entity that supports protocol identification, multiplexing, +and demultiplexing, for protocol data unit (PDU) transmission and reception +by one or more higher layer entities. + +It is described in 8.13.9 of IEEE Std 802.1Q-2022 that in a Bridge, the LLC +Entity associated with each Bridge Port is modeled as being directly +connected to the attached Local Area Network (LAN). + +On the switch with CPU port architecture, CPU port functions as Management +Port, and the Management Port functionality is provided by software which +functions as an end station. Software is connected to an IEEE 802 LAN that +is wholly contained within the system that incorporates the Bridge. +Software provides access to the LLC Entity associated with each Bridge Port +by the value of the source port field on the special tag on the frame +received by software. + +We call frames that carry control information to determine the active +topology and current extent of each Virtual Local Area Network (VLAN), +i.e., spanning tree or Shortest Path Bridging (SPB) and Multiple VLAN +Registration Protocol Data Units (MVRPDUs), and frames from other link +constrained protocols, such as Extensible Authentication Protocol over LAN +(EAPOL) and Link Layer Discovery Protocol (LLDP), link-local frames. They +are not forwarded by a Bridge. Permanently configured entries in the +filtering database (FDB) ensure that such frames are discarded by the +Forwarding Process. In 8.6.3 of IEEE Std 802.1Q-2022, this is described in +detail: + +Each of the reserved MAC addresses specified in Table 8-1 +(01-80-C2-00-00-[00,01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F]) shall be +permanently configured in the FDB in C-VLAN components and ERs. + +Each of the reserved MAC addresses specified in Table 8-2 +(01-80-C2-00-00-[01,02,03,04,05,06,07,08,09,0A,0E]) shall be permanently +configured in the FDB in S-VLAN components. + +Each of the reserved MAC addresses specified in Table 8-3 +(01-80-C2-00-00-[01,02,04,0E]) shall be permanently configured in the FDB +in TPMR components. + +The FDB entries for reserved MAC addresses shall specify filtering for all +Bridge Ports and all VIDs. Management shall not provide the capability to +modify or remove entries for reserved MAC addresses. + +The addresses in Table 8-1, Table 8-2, and Table 8-3 determine the scope of +propagation of PDUs within a Bridged Network, as follows: + + The Nearest Bridge group address (01-80-C2-00-00-0E) is an address that + no conformant Two-Port MAC Relay (TPMR) component, Service VLAN (S-VLAN) + component, Customer VLAN (C-VLAN) component, or MAC Bridge can forward. + PDUs transmitted using this destination address, or any other addresses + that appear in Table 8-1, Table 8-2, and Table 8-3 + (01-80-C2-00-00-[00,01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F]), can + therefore travel no further than those stations that can be reached via a + single individual LAN from the originating station. + + The Nearest non-TPMR Bridge group address (01-80-C2-00-00-03), is an + address that no conformant S-VLAN component, C-VLAN component, or MAC + Bridge can forward; however, this address is relayed by a TPMR component. + PDUs using this destination address, or any of the other addresses that + appear in both Table 8-1 and Table 8-2 but not in Table 8-3 + (01-80-C2-00-00-[00,03,05,06,07,08,09,0A,0B,0C,0D,0F]), will be relayed + by any TPMRs but will propagate no further than the nearest S-VLAN + component, C-VLAN component, or MAC Bridge. + + The Nearest Customer Bridge group address (01-80-C2-00-00-00) is an + address that no conformant C-VLAN component, MAC Bridge can forward; + however, it is relayed by TPMR components and S-VLAN components. PDUs + using this destination address, or any of the other addresses that appear + in Table 8-1 but not in either Table 8-2 or Table 8-3 + (01-80-C2-00-00-[00,0B,0C,0D,0F]), will be relayed by TPMR components and + S-VLAN components but will propagate no further than the nearest C-VLAN + component or MAC Bridge. + +Because the LLC Entity associated with each Bridge Port is provided via CPU +port, we must not filter these frames but forward them to CPU port. + +In a Bridge, the transmission Port is majorly decided by ingress and egress +rules, FDB, and spanning tree Port State functions of the Forwarding +Process. For link-local frames, only CPU port should be designated as +destination port in the FDB, and the other functions of the Forwarding +Process must not interfere with the decision of the transmission Port. We +call this process trapping frames to CPU port. + +Therefore, on the switch with CPU port architecture, link-local frames must +be trapped to CPU port, and certain link-local frames received by a Port of +a Bridge comprising a TPMR component or an S-VLAN component must be +excluded from it. + +A Bridge of the switch with CPU port architecture cannot comprise a +Two-Port MAC Relay (TPMR) component as a TPMR component supports only a +subset of the functionality of a MAC Bridge. A Bridge comprising two Ports +(Management Port doesn't count) of this architecture will either function +as a standard MAC Bridge or a standard VLAN Bridge. + +Therefore, a Bridge of this architecture can only comprise S-VLAN +components, C-VLAN components, or MAC Bridge components. Since there's no +TPMR component, we don't need to relay PDUs using the destination addresses +specified on the Nearest non-TPMR section, and the proportion of the +Nearest Customer Bridge section where they must be relayed by TPMR +components. + +One option to trap link-local frames to CPU port is to add static FDB +entries with CPU port designated as destination port. However, because that +Independent VLAN Learning (IVL) is being used on every VID, each entry only +applies to a single VLAN Identifier (VID). For a Bridge comprising a MAC +Bridge component or a C-VLAN component, there would have to be 16 times +4096 entries. This switch intellectual property can only hold a maximum of +2048 entries. Using this option, there also isn't a mechanism to prevent +link-local frames from being discarded when the spanning tree Port State of +the reception Port is discarding. + +The remaining option is to utilise the BPC, RGAC1, RGAC2, RGAC3, and RGAC4 +registers. Whilst this applies to every VID, it doesn't contain all of the +reserved MAC addresses without affecting the remaining Standard Group MAC +Addresses. The REV_UN frame tag utilised using the RGAC4 register covers +the remaining 01-80-C2-00-00-[04,05,06,07,08,09,0A,0B,0C,0D,0F] destination +addresses. It also includes the 01-80-C2-00-00-22 to 01-80-C2-00-00-FF +destination addresses which may be relayed by MAC Bridges or VLAN Bridges. +The latter option provides better but not complete conformance. + +This switch intellectual property also does not provide a mechanism to trap +link-local frames with specific destination addresses to CPU port by +Bridge, to conform to the filtering rules for the distinct Bridge +components. + +Therefore, regardless of the type of the Bridge component, link-local +frames with these destination addresses will be trapped to CPU port: + +01-80-C2-00-00-[00,01,02,03,0E] + +In a Bridge comprising a MAC Bridge component or a C-VLAN component: + + Link-local frames with these destination addresses won't be trapped to + CPU port which won't conform to IEEE Std 802.1Q-2022: + + 01-80-C2-00-00-[04,05,06,07,08,09,0A,0B,0C,0D,0F] + +In a Bridge comprising an S-VLAN component: + + Link-local frames with these destination addresses will be trapped to CPU + port which won't conform to IEEE Std 802.1Q-2022: + + 01-80-C2-00-00-00 + + Link-local frames with these destination addresses won't be trapped to + CPU port which won't conform to IEEE Std 802.1Q-2022: + + 01-80-C2-00-00-[04,05,06,07,08,09,0A] + +Currently on this switch intellectual property, if the spanning tree Port +State of the reception Port is discarding, link-local frames will be +discarded. + +To trap link-local frames regardless of the spanning tree Port State, make +the switch regard them as Bridge Protocol Data Units (BPDUs). This switch +intellectual property only lets the frames regarded as BPDUs bypass the +spanning tree Port State function of the Forwarding Process. + +With this change, the only remaining interference is the ingress rules. +When the reception Port has no PVID assigned on software, VLAN-untagged +frames won't be allowed in. There doesn't seem to be a mechanism on the +switch intellectual property to have link-local frames bypass this function +of the Forwarding Process. + +Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") +Reviewed-by: Daniel Golle +Signed-off-by: Arınç ÜNAL +--- + drivers/net/dsa/mt7530.c | 229 +++++++++++++++++++++++++++++++++------ + drivers/net/dsa/mt7530.h | 5 + + 2 files changed, 200 insertions(+), 34 deletions(-) + +--- a/drivers/net/dsa/mt7530.c ++++ b/drivers/net/dsa/mt7530.c +@@ -943,20 +943,173 @@ static void mt7530_setup_port5(struct ds + mutex_unlock(&priv->reg_mutex); + } + +-/* On page 205, section "8.6.3 Frame filtering" of the active standard, IEEE Std +- * 802.1Q™-2022, it is stated that frames with 01:80:C2:00:00:00-0F as MAC DA +- * must only be propagated to C-VLAN and MAC Bridge components. That means +- * VLAN-aware and VLAN-unaware bridges. On the switch designs with CPU ports, +- * these frames are supposed to be processed by the CPU (software). So we make +- * the switch only forward them to the CPU port. And if received from a CPU +- * port, forward to a single port. The software is responsible of making the +- * switch conform to the latter by setting a single port as destination port on +- * the special tag. +- * +- * This switch intellectual property cannot conform to this part of the standard +- * fully. Whilst the REV_UN frame tag covers the remaining :04-0D and :0F MAC +- * DAs, it also includes :22-FF which the scope of propagation is not supposed +- * to be restricted for these MAC DAs. ++/* In Clause 5 of IEEE Std 802-2014, two sublayers of the data link layer (DLL) ++ * of the Open Systems Interconnection basic reference model (OSI/RM) are ++ * described; the medium access control (MAC) and logical link control (LLC) ++ * sublayers. The MAC sublayer is the one facing the physical layer. ++ * ++ * In 8.2 of IEEE Std 802.1Q-2022, the Bridge architecture is described. A ++ * Bridge component comprises a MAC Relay Entity for interconnecting the Ports ++ * of the Bridge, at least two Ports, and higher layer entities with at least a ++ * Spanning Tree Protocol Entity included. ++ * ++ * Each Bridge Port also functions as an end station and shall provide the MAC ++ * Service to an LLC Entity. Each instance of the MAC Service is provided to a ++ * distinct LLC Entity that supports protocol identification, multiplexing, and ++ * demultiplexing, for protocol data unit (PDU) transmission and reception by ++ * one or more higher layer entities. ++ * ++ * It is described in 8.13.9 of IEEE Std 802.1Q-2022 that in a Bridge, the LLC ++ * Entity associated with each Bridge Port is modeled as being directly ++ * connected to the attached Local Area Network (LAN). ++ * ++ * On the switch with CPU port architecture, CPU port functions as Management ++ * Port, and the Management Port functionality is provided by software which ++ * functions as an end station. Software is connected to an IEEE 802 LAN that is ++ * wholly contained within the system that incorporates the Bridge. Software ++ * provides access to the LLC Entity associated with each Bridge Port by the ++ * value of the source port field on the special tag on the frame received by ++ * software. ++ * ++ * We call frames that carry control information to determine the active ++ * topology and current extent of each Virtual Local Area Network (VLAN), i.e., ++ * spanning tree or Shortest Path Bridging (SPB) and Multiple VLAN Registration ++ * Protocol Data Units (MVRPDUs), and frames from other link constrained ++ * protocols, such as Extensible Authentication Protocol over LAN (EAPOL) and ++ * Link Layer Discovery Protocol (LLDP), link-local frames. They are not ++ * forwarded by a Bridge. Permanently configured entries in the filtering ++ * database (FDB) ensure that such frames are discarded by the Forwarding ++ * Process. In 8.6.3 of IEEE Std 802.1Q-2022, this is described in detail: ++ * ++ * Each of the reserved MAC addresses specified in Table 8-1 ++ * (01-80-C2-00-00-[00,01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F]) shall be ++ * permanently configured in the FDB in C-VLAN components and ERs. ++ * ++ * Each of the reserved MAC addresses specified in Table 8-2 ++ * (01-80-C2-00-00-[01,02,03,04,05,06,07,08,09,0A,0E]) shall be permanently ++ * configured in the FDB in S-VLAN components. ++ * ++ * Each of the reserved MAC addresses specified in Table 8-3 ++ * (01-80-C2-00-00-[01,02,04,0E]) shall be permanently configured in the FDB in ++ * TPMR components. ++ * ++ * The FDB entries for reserved MAC addresses shall specify filtering for all ++ * Bridge Ports and all VIDs. Management shall not provide the capability to ++ * modify or remove entries for reserved MAC addresses. ++ * ++ * The addresses in Table 8-1, Table 8-2, and Table 8-3 determine the scope of ++ * propagation of PDUs within a Bridged Network, as follows: ++ * ++ * The Nearest Bridge group address (01-80-C2-00-00-0E) is an address that no ++ * conformant Two-Port MAC Relay (TPMR) component, Service VLAN (S-VLAN) ++ * component, Customer VLAN (C-VLAN) component, or MAC Bridge can forward. ++ * PDUs transmitted using this destination address, or any other addresses ++ * that appear in Table 8-1, Table 8-2, and Table 8-3 ++ * (01-80-C2-00-00-[00,01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F]), can ++ * therefore travel no further than those stations that can be reached via a ++ * single individual LAN from the originating station. ++ * ++ * The Nearest non-TPMR Bridge group address (01-80-C2-00-00-03), is an ++ * address that no conformant S-VLAN component, C-VLAN component, or MAC ++ * Bridge can forward; however, this address is relayed by a TPMR component. ++ * PDUs using this destination address, or any of the other addresses that ++ * appear in both Table 8-1 and Table 8-2 but not in Table 8-3 ++ * (01-80-C2-00-00-[00,03,05,06,07,08,09,0A,0B,0C,0D,0F]), will be relayed by ++ * any TPMRs but will propagate no further than the nearest S-VLAN component, ++ * C-VLAN component, or MAC Bridge. ++ * ++ * The Nearest Customer Bridge group address (01-80-C2-00-00-00) is an address ++ * that no conformant C-VLAN component, MAC Bridge can forward; however, it is ++ * relayed by TPMR components and S-VLAN components. PDUs using this ++ * destination address, or any of the other addresses that appear in Table 8-1 ++ * but not in either Table 8-2 or Table 8-3 (01-80-C2-00-00-[00,0B,0C,0D,0F]), ++ * will be relayed by TPMR components and S-VLAN components but will propagate ++ * no further than the nearest C-VLAN component or MAC Bridge. ++ * ++ * Because the LLC Entity associated with each Bridge Port is provided via CPU ++ * port, we must not filter these frames but forward them to CPU port. ++ * ++ * In a Bridge, the transmission Port is majorly decided by ingress and egress ++ * rules, FDB, and spanning tree Port State functions of the Forwarding Process. ++ * For link-local frames, only CPU port should be designated as destination port ++ * in the FDB, and the other functions of the Forwarding Process must not ++ * interfere with the decision of the transmission Port. We call this process ++ * trapping frames to CPU port. ++ * ++ * Therefore, on the switch with CPU port architecture, link-local frames must ++ * be trapped to CPU port, and certain link-local frames received by a Port of a ++ * Bridge comprising a TPMR component or an S-VLAN component must be excluded ++ * from it. ++ * ++ * A Bridge of the switch with CPU port architecture cannot comprise a Two-Port ++ * MAC Relay (TPMR) component as a TPMR component supports only a subset of the ++ * functionality of a MAC Bridge. A Bridge comprising two Ports (Management Port ++ * doesn't count) of this architecture will either function as a standard MAC ++ * Bridge or a standard VLAN Bridge. ++ * ++ * Therefore, a Bridge of this architecture can only comprise S-VLAN components, ++ * C-VLAN components, or MAC Bridge components. Since there's no TPMR component, ++ * we don't need to relay PDUs using the destination addresses specified on the ++ * Nearest non-TPMR section, and the proportion of the Nearest Customer Bridge ++ * section where they must be relayed by TPMR components. ++ * ++ * One option to trap link-local frames to CPU port is to add static FDB entries ++ * with CPU port designated as destination port. However, because that ++ * Independent VLAN Learning (IVL) is being used on every VID, each entry only ++ * applies to a single VLAN Identifier (VID). For a Bridge comprising a MAC ++ * Bridge component or a C-VLAN component, there would have to be 16 times 4096 ++ * entries. This switch intellectual property can only hold a maximum of 2048 ++ * entries. Using this option, there also isn't a mechanism to prevent ++ * link-local frames from being discarded when the spanning tree Port State of ++ * the reception Port is discarding. ++ * ++ * The remaining option is to utilise the BPC, RGAC1, RGAC2, RGAC3, and RGAC4 ++ * registers. Whilst this applies to every VID, it doesn't contain all of the ++ * reserved MAC addresses without affecting the remaining Standard Group MAC ++ * Addresses. The REV_UN frame tag utilised using the RGAC4 register covers the ++ * remaining 01-80-C2-00-00-[04,05,06,07,08,09,0A,0B,0C,0D,0F] destination ++ * addresses. It also includes the 01-80-C2-00-00-22 to 01-80-C2-00-00-FF ++ * destination addresses which may be relayed by MAC Bridges or VLAN Bridges. ++ * The latter option provides better but not complete conformance. ++ * ++ * This switch intellectual property also does not provide a mechanism to trap ++ * link-local frames with specific destination addresses to CPU port by Bridge, ++ * to conform to the filtering rules for the distinct Bridge components. ++ * ++ * Therefore, regardless of the type of the Bridge component, link-local frames ++ * with these destination addresses will be trapped to CPU port: ++ * ++ * 01-80-C2-00-00-[00,01,02,03,0E] ++ * ++ * In a Bridge comprising a MAC Bridge component or a C-VLAN component: ++ * ++ * Link-local frames with these destination addresses won't be trapped to CPU ++ * port which won't conform to IEEE Std 802.1Q-2022: ++ * ++ * 01-80-C2-00-00-[04,05,06,07,08,09,0A,0B,0C,0D,0F] ++ * ++ * In a Bridge comprising an S-VLAN component: ++ * ++ * Link-local frames with these destination addresses will be trapped to CPU ++ * port which won't conform to IEEE Std 802.1Q-2022: ++ * ++ * 01-80-C2-00-00-00 ++ * ++ * Link-local frames with these destination addresses won't be trapped to CPU ++ * port which won't conform to IEEE Std 802.1Q-2022: ++ * ++ * 01-80-C2-00-00-[04,05,06,07,08,09,0A] ++ * ++ * To trap link-local frames to CPU port as conformant as this switch ++ * intellectual property can allow, link-local frames are made to be regarded as ++ * Bridge Protocol Data Units (BPDUs). This is because this switch intellectual ++ * property only lets the frames regarded as BPDUs bypass the spanning tree Port ++ * State function of the Forwarding Process. ++ * ++ * The only remaining interference is the ingress rules. When the reception Port ++ * has no PVID assigned on software, VLAN-untagged frames won't be allowed in. ++ * There doesn't seem to be a mechanism on the switch intellectual property to ++ * have link-local frames bypass this function of the Forwarding Process. + */ + static void + mt753x_trap_frames(struct mt7530_priv *priv) +@@ -964,35 +1117,43 @@ mt753x_trap_frames(struct mt7530_priv *p + /* Trap 802.1X PAE frames and BPDUs to the CPU port(s) and egress them + * VLAN-untagged. + */ +- mt7530_rmw(priv, MT753X_BPC, MT753X_PAE_EG_TAG_MASK | +- MT753X_PAE_PORT_FW_MASK | MT753X_BPDU_EG_TAG_MASK | +- MT753X_BPDU_PORT_FW_MASK, +- MT753X_PAE_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | +- MT753X_PAE_PORT_FW(MT753X_BPDU_CPU_ONLY) | +- MT753X_BPDU_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | +- MT753X_BPDU_CPU_ONLY); ++ mt7530_rmw(priv, MT753X_BPC, ++ MT753X_PAE_BPDU_FR | MT753X_PAE_EG_TAG_MASK | ++ MT753X_PAE_PORT_FW_MASK | MT753X_BPDU_EG_TAG_MASK | ++ MT753X_BPDU_PORT_FW_MASK, ++ MT753X_PAE_BPDU_FR | ++ MT753X_PAE_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | ++ MT753X_PAE_PORT_FW(MT753X_BPDU_CPU_ONLY) | ++ MT753X_BPDU_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | ++ MT753X_BPDU_CPU_ONLY); + + /* Trap frames with :01 and :02 MAC DAs to the CPU port(s) and egress + * them VLAN-untagged. + */ +- mt7530_rmw(priv, MT753X_RGAC1, MT753X_R02_EG_TAG_MASK | +- MT753X_R02_PORT_FW_MASK | MT753X_R01_EG_TAG_MASK | +- MT753X_R01_PORT_FW_MASK, +- MT753X_R02_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | +- MT753X_R02_PORT_FW(MT753X_BPDU_CPU_ONLY) | +- MT753X_R01_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | +- MT753X_BPDU_CPU_ONLY); ++ mt7530_rmw(priv, MT753X_RGAC1, ++ MT753X_R02_BPDU_FR | MT753X_R02_EG_TAG_MASK | ++ MT753X_R02_PORT_FW_MASK | MT753X_R01_BPDU_FR | ++ MT753X_R01_EG_TAG_MASK | MT753X_R01_PORT_FW_MASK, ++ MT753X_R02_BPDU_FR | ++ MT753X_R02_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | ++ MT753X_R02_PORT_FW(MT753X_BPDU_CPU_ONLY) | ++ MT753X_R01_BPDU_FR | ++ MT753X_R01_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | ++ MT753X_BPDU_CPU_ONLY); + + /* Trap frames with :03 and :0E MAC DAs to the CPU port(s) and egress + * them VLAN-untagged. + */ +- mt7530_rmw(priv, MT753X_RGAC2, MT753X_R0E_EG_TAG_MASK | +- MT753X_R0E_PORT_FW_MASK | MT753X_R03_EG_TAG_MASK | +- MT753X_R03_PORT_FW_MASK, +- MT753X_R0E_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | +- MT753X_R0E_PORT_FW(MT753X_BPDU_CPU_ONLY) | +- MT753X_R03_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | +- MT753X_BPDU_CPU_ONLY); ++ mt7530_rmw(priv, MT753X_RGAC2, ++ MT753X_R0E_BPDU_FR | MT753X_R0E_EG_TAG_MASK | ++ MT753X_R0E_PORT_FW_MASK | MT753X_R03_BPDU_FR | ++ MT753X_R03_EG_TAG_MASK | MT753X_R03_PORT_FW_MASK, ++ MT753X_R0E_BPDU_FR | ++ MT753X_R0E_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | ++ MT753X_R0E_PORT_FW(MT753X_BPDU_CPU_ONLY) | ++ MT753X_R03_BPDU_FR | ++ MT753X_R03_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | ++ MT753X_BPDU_CPU_ONLY); + } + + static void +--- a/drivers/net/dsa/mt7530.h ++++ b/drivers/net/dsa/mt7530.h +@@ -65,6 +65,7 @@ enum mt753x_id { + + /* Registers for BPDU and PAE frame control*/ + #define MT753X_BPC 0x24 ++#define MT753X_PAE_BPDU_FR BIT(25) + #define MT753X_PAE_EG_TAG_MASK GENMASK(24, 22) + #define MT753X_PAE_EG_TAG(x) FIELD_PREP(MT753X_PAE_EG_TAG_MASK, x) + #define MT753X_PAE_PORT_FW_MASK GENMASK(18, 16) +@@ -75,20 +76,24 @@ enum mt753x_id { + + /* Register for :01 and :02 MAC DA frame control */ + #define MT753X_RGAC1 0x28 ++#define MT753X_R02_BPDU_FR BIT(25) + #define MT753X_R02_EG_TAG_MASK GENMASK(24, 22) + #define MT753X_R02_EG_TAG(x) FIELD_PREP(MT753X_R02_EG_TAG_MASK, x) + #define MT753X_R02_PORT_FW_MASK GENMASK(18, 16) + #define MT753X_R02_PORT_FW(x) FIELD_PREP(MT753X_R02_PORT_FW_MASK, x) ++#define MT753X_R01_BPDU_FR BIT(9) + #define MT753X_R01_EG_TAG_MASK GENMASK(8, 6) + #define MT753X_R01_EG_TAG(x) FIELD_PREP(MT753X_R01_EG_TAG_MASK, x) + #define MT753X_R01_PORT_FW_MASK GENMASK(2, 0) + + /* Register for :03 and :0E MAC DA frame control */ + #define MT753X_RGAC2 0x2c ++#define MT753X_R0E_BPDU_FR BIT(25) + #define MT753X_R0E_EG_TAG_MASK GENMASK(24, 22) + #define MT753X_R0E_EG_TAG(x) FIELD_PREP(MT753X_R0E_EG_TAG_MASK, x) + #define MT753X_R0E_PORT_FW_MASK GENMASK(18, 16) + #define MT753X_R0E_PORT_FW(x) FIELD_PREP(MT753X_R0E_PORT_FW_MASK, x) ++#define MT753X_R03_BPDU_FR BIT(9) + #define MT753X_R03_EG_TAG_MASK GENMASK(8, 6) + #define MT753X_R03_EG_TAG(x) FIELD_PREP(MT753X_R03_EG_TAG_MASK, x) + #define MT753X_R03_PORT_FW_MASK GENMASK(2, 0) diff --git a/target/linux/generic/backport-6.6/790-31-v6.10-net-dsa-mt7530-fix-enabling-EEE-on-MT7531-switch-on-.patch b/target/linux/generic/backport-6.6/790-31-v6.10-net-dsa-mt7530-fix-enabling-EEE-on-MT7531-switch-on-.patch new file mode 100644 index 000000000000..9a4d4a918a80 --- /dev/null +++ b/target/linux/generic/backport-6.6/790-31-v6.10-net-dsa-mt7530-fix-enabling-EEE-on-MT7531-switch-on-.patch @@ -0,0 +1,92 @@ +From ef972fc9f5743da589ce9546dd565d6c56e679b8 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ar=C4=B1n=C3=A7=20=C3=9CNAL?= +Date: Mon, 8 Apr 2024 10:08:53 +0300 +Subject: [PATCH 1/2] net: dsa: mt7530: fix enabling EEE on MT7531 switch on + all boards +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +The commit 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE features") +brought EEE support but did not enable EEE on MT7531 switch MACs. EEE is +enabled on MT7531 switch MACs by pulling the LAN2LED0 pin low on the board +(bootstrapping), unsetting the EEE_DIS bit on the trap register, or setting +the internal EEE switch bit on the CORE_PLL_GROUP4 register. Thanks to +SkyLake Huang (黃啟澤) from MediaTek for providing information on the +internal EEE switch bit. + +There are existing boards that were not designed to pull the pin low. +Because of that, the EEE status currently depends on the board design. + +The EEE_DIS bit on the trap pertains to the LAN2LED0 pin which is usually +used to control an LED. Once the bit is unset, the pin will be low. That +will make the active low LED turn on. The pin is controlled by the switch +PHY. It seems that the PHY controls the pin in the way that it inverts the +pin state. That means depending on the wiring of the LED connected to +LAN2LED0 on the board, the LED may be on without an active link. + +To not cause this unwanted behaviour whilst enabling EEE on all boards, set +the internal EEE switch bit on the CORE_PLL_GROUP4 register. + +My testing on MT7531 shows a certain amount of traffic loss when EEE is +enabled. That said, I haven't come across a board that enables EEE. So +enable EEE on the switch MACs but disable EEE advertisement on the switch +PHYs. This way, we don't change the behaviour of the majority of the boards +that have this switch. The mediatek-ge PHY driver already disables EEE +advertisement on the switch PHYs but my testing shows that it is somehow +enabled afterwards. Disabling EEE advertisement before the PHY driver +initialises keeps it off. + +With this change, EEE can now be enabled using ethtool. + +Fixes: 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE features") +Reviewed-by: Florian Fainelli +Signed-off-by: Arınç ÜNAL +--- + drivers/net/dsa/mt7530.c | 17 ++++++++++++----- + drivers/net/dsa/mt7530.h | 1 + + 2 files changed, 13 insertions(+), 5 deletions(-) + +--- a/drivers/net/dsa/mt7530.c ++++ b/drivers/net/dsa/mt7530.c +@@ -2666,18 +2666,25 @@ mt7531_setup(struct dsa_switch *ds) + mt7530_rmw(priv, MT7531_GPIO_MODE0, MT7531_GPIO0_MASK, + MT7531_GPIO0_INTERRUPT); + +- /* Enable PHY core PLL, since phy_device has not yet been created +- * provided for phy_[read,write]_mmd_indirect is called, we provide +- * our own mt7531_ind_mmd_phy_[read,write] to complete this +- * function. ++ /* Enable Energy-Efficient Ethernet (EEE) and PHY core PLL, since ++ * phy_device has not yet been created provided for ++ * phy_[read,write]_mmd_indirect is called, we provide our own ++ * mt7531_ind_mmd_phy_[read,write] to complete this function. + */ + val = mt7531_ind_c45_phy_read(priv, MT753X_CTRL_PHY_ADDR, + MDIO_MMD_VEND2, CORE_PLL_GROUP4); +- val |= MT7531_PHY_PLL_BYPASS_MODE; ++ val |= MT7531_RG_SYSPLL_DMY2 | MT7531_PHY_PLL_BYPASS_MODE; + val &= ~MT7531_PHY_PLL_OFF; + mt7531_ind_c45_phy_write(priv, MT753X_CTRL_PHY_ADDR, MDIO_MMD_VEND2, + CORE_PLL_GROUP4, val); + ++ /* Disable EEE advertisement on the switch PHYs. */ ++ for (i = MT753X_CTRL_PHY_ADDR; ++ i < MT753X_CTRL_PHY_ADDR + MT7530_NUM_PHYS; i++) { ++ mt7531_ind_c45_phy_write(priv, i, MDIO_MMD_AN, MDIO_AN_EEE_ADV, ++ 0); ++ } ++ + mt7531_setup_common(ds); + + /* Setup VLAN ID 0 for VLAN-unaware bridges */ +--- a/drivers/net/dsa/mt7530.h ++++ b/drivers/net/dsa/mt7530.h +@@ -621,6 +621,7 @@ enum mt7531_clk_skew { + #define RG_SYSPLL_DDSFBK_EN BIT(12) + #define RG_SYSPLL_BIAS_EN BIT(11) + #define RG_SYSPLL_BIAS_LPF_EN BIT(10) ++#define MT7531_RG_SYSPLL_DMY2 BIT(6) + #define MT7531_PHY_PLL_OFF BIT(5) + #define MT7531_PHY_PLL_BYPASS_MODE BIT(4) + diff --git a/target/linux/generic/pending-6.1/795-net-dsa-mt7530-fix-enabling-EEE-on-MT7531-switch-on-.patch b/target/linux/generic/pending-6.1/795-net-dsa-mt7530-fix-enabling-EEE-on-MT7531-switch-on-.patch deleted file mode 100644 index dc202a55e69d..000000000000 --- a/target/linux/generic/pending-6.1/795-net-dsa-mt7530-fix-enabling-EEE-on-MT7531-switch-on-.patch +++ /dev/null @@ -1,92 +0,0 @@ -From ef972fc9f5743da589ce9546dd565d6c56e679b8 Mon Sep 17 00:00:00 2001 -From: =?UTF-8?q?Ar=C4=B1n=C3=A7=20=C3=9CNAL?= -Date: Mon, 8 Apr 2024 10:08:53 +0300 -Subject: [PATCH 1/2] net: dsa: mt7530: fix enabling EEE on MT7531 switch on - all boards -MIME-Version: 1.0 -Content-Type: text/plain; charset=UTF-8 -Content-Transfer-Encoding: 8bit - -The commit 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE features") -brought EEE support but did not enable EEE on MT7531 switch MACs. EEE is -enabled on MT7531 switch MACs by pulling the LAN2LED0 pin low on the board -(bootstrapping), unsetting the EEE_DIS bit on the trap register, or setting -the internal EEE switch bit on the CORE_PLL_GROUP4 register. Thanks to -SkyLake Huang (黃啟澤) from MediaTek for providing information on the -internal EEE switch bit. - -There are existing boards that were not designed to pull the pin low. -Because of that, the EEE status currently depends on the board design. - -The EEE_DIS bit on the trap pertains to the LAN2LED0 pin which is usually -used to control an LED. Once the bit is unset, the pin will be low. That -will make the active low LED turn on. The pin is controlled by the switch -PHY. It seems that the PHY controls the pin in the way that it inverts the -pin state. That means depending on the wiring of the LED connected to -LAN2LED0 on the board, the LED may be on without an active link. - -To not cause this unwanted behaviour whilst enabling EEE on all boards, set -the internal EEE switch bit on the CORE_PLL_GROUP4 register. - -My testing on MT7531 shows a certain amount of traffic loss when EEE is -enabled. That said, I haven't come across a board that enables EEE. So -enable EEE on the switch MACs but disable EEE advertisement on the switch -PHYs. This way, we don't change the behaviour of the majority of the boards -that have this switch. The mediatek-ge PHY driver already disables EEE -advertisement on the switch PHYs but my testing shows that it is somehow -enabled afterwards. Disabling EEE advertisement before the PHY driver -initialises keeps it off. - -With this change, EEE can now be enabled using ethtool. - -Fixes: 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE features") -Reviewed-by: Florian Fainelli -Signed-off-by: Arınç ÜNAL ---- - drivers/net/dsa/mt7530.c | 17 ++++++++++++----- - drivers/net/dsa/mt7530.h | 1 + - 2 files changed, 13 insertions(+), 5 deletions(-) - ---- a/drivers/net/dsa/mt7530.c -+++ b/drivers/net/dsa/mt7530.c -@@ -2496,18 +2496,25 @@ mt7531_setup(struct dsa_switch *ds) - mt7530_rmw(priv, MT7531_GPIO_MODE0, MT7531_GPIO0_MASK, - MT7531_GPIO0_INTERRUPT); - -- /* Enable PHY core PLL, since phy_device has not yet been created -- * provided for phy_[read,write]_mmd_indirect is called, we provide -- * our own mt7531_ind_mmd_phy_[read,write] to complete this -- * function. -+ /* Enable Energy-Efficient Ethernet (EEE) and PHY core PLL, since -+ * phy_device has not yet been created provided for -+ * phy_[read,write]_mmd_indirect is called, we provide our own -+ * mt7531_ind_mmd_phy_[read,write] to complete this function. - */ - val = mt7531_ind_c45_phy_read(priv, MT753X_CTRL_PHY_ADDR, - MDIO_MMD_VEND2, CORE_PLL_GROUP4); -- val |= MT7531_PHY_PLL_BYPASS_MODE; -+ val |= MT7531_RG_SYSPLL_DMY2 | MT7531_PHY_PLL_BYPASS_MODE; - val &= ~MT7531_PHY_PLL_OFF; - mt7531_ind_c45_phy_write(priv, MT753X_CTRL_PHY_ADDR, MDIO_MMD_VEND2, - CORE_PLL_GROUP4, val); - -+ /* Disable EEE advertisement on the switch PHYs. */ -+ for (i = MT753X_CTRL_PHY_ADDR; -+ i < MT753X_CTRL_PHY_ADDR + MT7530_NUM_PHYS; i++) { -+ mt7531_ind_c45_phy_write(priv, i, MDIO_MMD_AN, MDIO_AN_EEE_ADV, -+ 0); -+ } -+ - mt7531_setup_common(ds); - - /* Setup VLAN ID 0 for VLAN-unaware bridges */ ---- a/drivers/net/dsa/mt7530.h -+++ b/drivers/net/dsa/mt7530.h -@@ -616,6 +616,7 @@ enum mt7531_clk_skew { - #define RG_SYSPLL_DDSFBK_EN BIT(12) - #define RG_SYSPLL_BIAS_EN BIT(11) - #define RG_SYSPLL_BIAS_LPF_EN BIT(10) -+#define MT7531_RG_SYSPLL_DMY2 BIT(6) - #define MT7531_PHY_PLL_OFF BIT(5) - #define MT7531_PHY_PLL_BYPASS_MODE BIT(4) - diff --git a/target/linux/generic/pending-6.1/796-net-dsa-mt7530-trap-link-local-frames-regardless-of-.patch b/target/linux/generic/pending-6.1/796-net-dsa-mt7530-trap-link-local-frames-regardless-of-.patch deleted file mode 100644 index 4d70e774a4d5..000000000000 --- a/target/linux/generic/pending-6.1/796-net-dsa-mt7530-trap-link-local-frames-regardless-of-.patch +++ /dev/null @@ -1,483 +0,0 @@ -From b7427d66cb3d6dca5165de5f7d80d59f08c2795b Mon Sep 17 00:00:00 2001 -From: =?UTF-8?q?Ar=C4=B1n=C3=A7=20=C3=9CNAL?= -Date: Tue, 9 Apr 2024 18:01:14 +0300 -Subject: [PATCH 2/2] net: dsa: mt7530: trap link-local frames regardless of ST - Port State -MIME-Version: 1.0 -Content-Type: text/plain; charset=UTF-8 -Content-Transfer-Encoding: 8bit - -In Clause 5 of IEEE Std 802-2014, two sublayers of the data link layer -(DLL) of the Open Systems Interconnection basic reference model (OSI/RM) -are described; the medium access control (MAC) and logical link control -(LLC) sublayers. The MAC sublayer is the one facing the physical layer. - -In 8.2 of IEEE Std 802.1Q-2022, the Bridge architecture is described. A -Bridge component comprises a MAC Relay Entity for interconnecting the Ports -of the Bridge, at least two Ports, and higher layer entities with at least -a Spanning Tree Protocol Entity included. - -Each Bridge Port also functions as an end station and shall provide the MAC -Service to an LLC Entity. Each instance of the MAC Service is provided to a -distinct LLC Entity that supports protocol identification, multiplexing, -and demultiplexing, for protocol data unit (PDU) transmission and reception -by one or more higher layer entities. - -It is described in 8.13.9 of IEEE Std 802.1Q-2022 that in a Bridge, the LLC -Entity associated with each Bridge Port is modeled as being directly -connected to the attached Local Area Network (LAN). - -On the switch with CPU port architecture, CPU port functions as Management -Port, and the Management Port functionality is provided by software which -functions as an end station. Software is connected to an IEEE 802 LAN that -is wholly contained within the system that incorporates the Bridge. -Software provides access to the LLC Entity associated with each Bridge Port -by the value of the source port field on the special tag on the frame -received by software. - -We call frames that carry control information to determine the active -topology and current extent of each Virtual Local Area Network (VLAN), -i.e., spanning tree or Shortest Path Bridging (SPB) and Multiple VLAN -Registration Protocol Data Units (MVRPDUs), and frames from other link -constrained protocols, such as Extensible Authentication Protocol over LAN -(EAPOL) and Link Layer Discovery Protocol (LLDP), link-local frames. They -are not forwarded by a Bridge. Permanently configured entries in the -filtering database (FDB) ensure that such frames are discarded by the -Forwarding Process. In 8.6.3 of IEEE Std 802.1Q-2022, this is described in -detail: - -Each of the reserved MAC addresses specified in Table 8-1 -(01-80-C2-00-00-[00,01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F]) shall be -permanently configured in the FDB in C-VLAN components and ERs. - -Each of the reserved MAC addresses specified in Table 8-2 -(01-80-C2-00-00-[01,02,03,04,05,06,07,08,09,0A,0E]) shall be permanently -configured in the FDB in S-VLAN components. - -Each of the reserved MAC addresses specified in Table 8-3 -(01-80-C2-00-00-[01,02,04,0E]) shall be permanently configured in the FDB -in TPMR components. - -The FDB entries for reserved MAC addresses shall specify filtering for all -Bridge Ports and all VIDs. Management shall not provide the capability to -modify or remove entries for reserved MAC addresses. - -The addresses in Table 8-1, Table 8-2, and Table 8-3 determine the scope of -propagation of PDUs within a Bridged Network, as follows: - - The Nearest Bridge group address (01-80-C2-00-00-0E) is an address that - no conformant Two-Port MAC Relay (TPMR) component, Service VLAN (S-VLAN) - component, Customer VLAN (C-VLAN) component, or MAC Bridge can forward. - PDUs transmitted using this destination address, or any other addresses - that appear in Table 8-1, Table 8-2, and Table 8-3 - (01-80-C2-00-00-[00,01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F]), can - therefore travel no further than those stations that can be reached via a - single individual LAN from the originating station. - - The Nearest non-TPMR Bridge group address (01-80-C2-00-00-03), is an - address that no conformant S-VLAN component, C-VLAN component, or MAC - Bridge can forward; however, this address is relayed by a TPMR component. - PDUs using this destination address, or any of the other addresses that - appear in both Table 8-1 and Table 8-2 but not in Table 8-3 - (01-80-C2-00-00-[00,03,05,06,07,08,09,0A,0B,0C,0D,0F]), will be relayed - by any TPMRs but will propagate no further than the nearest S-VLAN - component, C-VLAN component, or MAC Bridge. - - The Nearest Customer Bridge group address (01-80-C2-00-00-00) is an - address that no conformant C-VLAN component, MAC Bridge can forward; - however, it is relayed by TPMR components and S-VLAN components. PDUs - using this destination address, or any of the other addresses that appear - in Table 8-1 but not in either Table 8-2 or Table 8-3 - (01-80-C2-00-00-[00,0B,0C,0D,0F]), will be relayed by TPMR components and - S-VLAN components but will propagate no further than the nearest C-VLAN - component or MAC Bridge. - -Because the LLC Entity associated with each Bridge Port is provided via CPU -port, we must not filter these frames but forward them to CPU port. - -In a Bridge, the transmission Port is majorly decided by ingress and egress -rules, FDB, and spanning tree Port State functions of the Forwarding -Process. For link-local frames, only CPU port should be designated as -destination port in the FDB, and the other functions of the Forwarding -Process must not interfere with the decision of the transmission Port. We -call this process trapping frames to CPU port. - -Therefore, on the switch with CPU port architecture, link-local frames must -be trapped to CPU port, and certain link-local frames received by a Port of -a Bridge comprising a TPMR component or an S-VLAN component must be -excluded from it. - -A Bridge of the switch with CPU port architecture cannot comprise a -Two-Port MAC Relay (TPMR) component as a TPMR component supports only a -subset of the functionality of a MAC Bridge. A Bridge comprising two Ports -(Management Port doesn't count) of this architecture will either function -as a standard MAC Bridge or a standard VLAN Bridge. - -Therefore, a Bridge of this architecture can only comprise S-VLAN -components, C-VLAN components, or MAC Bridge components. Since there's no -TPMR component, we don't need to relay PDUs using the destination addresses -specified on the Nearest non-TPMR section, and the proportion of the -Nearest Customer Bridge section where they must be relayed by TPMR -components. - -One option to trap link-local frames to CPU port is to add static FDB -entries with CPU port designated as destination port. However, because that -Independent VLAN Learning (IVL) is being used on every VID, each entry only -applies to a single VLAN Identifier (VID). For a Bridge comprising a MAC -Bridge component or a C-VLAN component, there would have to be 16 times -4096 entries. This switch intellectual property can only hold a maximum of -2048 entries. Using this option, there also isn't a mechanism to prevent -link-local frames from being discarded when the spanning tree Port State of -the reception Port is discarding. - -The remaining option is to utilise the BPC, RGAC1, RGAC2, RGAC3, and RGAC4 -registers. Whilst this applies to every VID, it doesn't contain all of the -reserved MAC addresses without affecting the remaining Standard Group MAC -Addresses. The REV_UN frame tag utilised using the RGAC4 register covers -the remaining 01-80-C2-00-00-[04,05,06,07,08,09,0A,0B,0C,0D,0F] destination -addresses. It also includes the 01-80-C2-00-00-22 to 01-80-C2-00-00-FF -destination addresses which may be relayed by MAC Bridges or VLAN Bridges. -The latter option provides better but not complete conformance. - -This switch intellectual property also does not provide a mechanism to trap -link-local frames with specific destination addresses to CPU port by -Bridge, to conform to the filtering rules for the distinct Bridge -components. - -Therefore, regardless of the type of the Bridge component, link-local -frames with these destination addresses will be trapped to CPU port: - -01-80-C2-00-00-[00,01,02,03,0E] - -In a Bridge comprising a MAC Bridge component or a C-VLAN component: - - Link-local frames with these destination addresses won't be trapped to - CPU port which won't conform to IEEE Std 802.1Q-2022: - - 01-80-C2-00-00-[04,05,06,07,08,09,0A,0B,0C,0D,0F] - -In a Bridge comprising an S-VLAN component: - - Link-local frames with these destination addresses will be trapped to CPU - port which won't conform to IEEE Std 802.1Q-2022: - - 01-80-C2-00-00-00 - - Link-local frames with these destination addresses won't be trapped to - CPU port which won't conform to IEEE Std 802.1Q-2022: - - 01-80-C2-00-00-[04,05,06,07,08,09,0A] - -Currently on this switch intellectual property, if the spanning tree Port -State of the reception Port is discarding, link-local frames will be -discarded. - -To trap link-local frames regardless of the spanning tree Port State, make -the switch regard them as Bridge Protocol Data Units (BPDUs). This switch -intellectual property only lets the frames regarded as BPDUs bypass the -spanning tree Port State function of the Forwarding Process. - -With this change, the only remaining interference is the ingress rules. -When the reception Port has no PVID assigned on software, VLAN-untagged -frames won't be allowed in. There doesn't seem to be a mechanism on the -switch intellectual property to have link-local frames bypass this function -of the Forwarding Process. - -Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") -Reviewed-by: Daniel Golle -Signed-off-by: Arınç ÜNAL ---- - drivers/net/dsa/mt7530.c | 229 +++++++++++++++++++++++++++++++++------ - drivers/net/dsa/mt7530.h | 5 + - 2 files changed, 200 insertions(+), 34 deletions(-) - ---- a/drivers/net/dsa/mt7530.c -+++ b/drivers/net/dsa/mt7530.c -@@ -943,20 +943,173 @@ static void mt7530_setup_port5(struct ds - mutex_unlock(&priv->reg_mutex); - } - --/* On page 205, section "8.6.3 Frame filtering" of the active standard, IEEE Std -- * 802.1Q™-2022, it is stated that frames with 01:80:C2:00:00:00-0F as MAC DA -- * must only be propagated to C-VLAN and MAC Bridge components. That means -- * VLAN-aware and VLAN-unaware bridges. On the switch designs with CPU ports, -- * these frames are supposed to be processed by the CPU (software). So we make -- * the switch only forward them to the CPU port. And if received from a CPU -- * port, forward to a single port. The software is responsible of making the -- * switch conform to the latter by setting a single port as destination port on -- * the special tag. -- * -- * This switch intellectual property cannot conform to this part of the standard -- * fully. Whilst the REV_UN frame tag covers the remaining :04-0D and :0F MAC -- * DAs, it also includes :22-FF which the scope of propagation is not supposed -- * to be restricted for these MAC DAs. -+/* In Clause 5 of IEEE Std 802-2014, two sublayers of the data link layer (DLL) -+ * of the Open Systems Interconnection basic reference model (OSI/RM) are -+ * described; the medium access control (MAC) and logical link control (LLC) -+ * sublayers. The MAC sublayer is the one facing the physical layer. -+ * -+ * In 8.2 of IEEE Std 802.1Q-2022, the Bridge architecture is described. A -+ * Bridge component comprises a MAC Relay Entity for interconnecting the Ports -+ * of the Bridge, at least two Ports, and higher layer entities with at least a -+ * Spanning Tree Protocol Entity included. -+ * -+ * Each Bridge Port also functions as an end station and shall provide the MAC -+ * Service to an LLC Entity. Each instance of the MAC Service is provided to a -+ * distinct LLC Entity that supports protocol identification, multiplexing, and -+ * demultiplexing, for protocol data unit (PDU) transmission and reception by -+ * one or more higher layer entities. -+ * -+ * It is described in 8.13.9 of IEEE Std 802.1Q-2022 that in a Bridge, the LLC -+ * Entity associated with each Bridge Port is modeled as being directly -+ * connected to the attached Local Area Network (LAN). -+ * -+ * On the switch with CPU port architecture, CPU port functions as Management -+ * Port, and the Management Port functionality is provided by software which -+ * functions as an end station. Software is connected to an IEEE 802 LAN that is -+ * wholly contained within the system that incorporates the Bridge. Software -+ * provides access to the LLC Entity associated with each Bridge Port by the -+ * value of the source port field on the special tag on the frame received by -+ * software. -+ * -+ * We call frames that carry control information to determine the active -+ * topology and current extent of each Virtual Local Area Network (VLAN), i.e., -+ * spanning tree or Shortest Path Bridging (SPB) and Multiple VLAN Registration -+ * Protocol Data Units (MVRPDUs), and frames from other link constrained -+ * protocols, such as Extensible Authentication Protocol over LAN (EAPOL) and -+ * Link Layer Discovery Protocol (LLDP), link-local frames. They are not -+ * forwarded by a Bridge. Permanently configured entries in the filtering -+ * database (FDB) ensure that such frames are discarded by the Forwarding -+ * Process. In 8.6.3 of IEEE Std 802.1Q-2022, this is described in detail: -+ * -+ * Each of the reserved MAC addresses specified in Table 8-1 -+ * (01-80-C2-00-00-[00,01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F]) shall be -+ * permanently configured in the FDB in C-VLAN components and ERs. -+ * -+ * Each of the reserved MAC addresses specified in Table 8-2 -+ * (01-80-C2-00-00-[01,02,03,04,05,06,07,08,09,0A,0E]) shall be permanently -+ * configured in the FDB in S-VLAN components. -+ * -+ * Each of the reserved MAC addresses specified in Table 8-3 -+ * (01-80-C2-00-00-[01,02,04,0E]) shall be permanently configured in the FDB in -+ * TPMR components. -+ * -+ * The FDB entries for reserved MAC addresses shall specify filtering for all -+ * Bridge Ports and all VIDs. Management shall not provide the capability to -+ * modify or remove entries for reserved MAC addresses. -+ * -+ * The addresses in Table 8-1, Table 8-2, and Table 8-3 determine the scope of -+ * propagation of PDUs within a Bridged Network, as follows: -+ * -+ * The Nearest Bridge group address (01-80-C2-00-00-0E) is an address that no -+ * conformant Two-Port MAC Relay (TPMR) component, Service VLAN (S-VLAN) -+ * component, Customer VLAN (C-VLAN) component, or MAC Bridge can forward. -+ * PDUs transmitted using this destination address, or any other addresses -+ * that appear in Table 8-1, Table 8-2, and Table 8-3 -+ * (01-80-C2-00-00-[00,01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F]), can -+ * therefore travel no further than those stations that can be reached via a -+ * single individual LAN from the originating station. -+ * -+ * The Nearest non-TPMR Bridge group address (01-80-C2-00-00-03), is an -+ * address that no conformant S-VLAN component, C-VLAN component, or MAC -+ * Bridge can forward; however, this address is relayed by a TPMR component. -+ * PDUs using this destination address, or any of the other addresses that -+ * appear in both Table 8-1 and Table 8-2 but not in Table 8-3 -+ * (01-80-C2-00-00-[00,03,05,06,07,08,09,0A,0B,0C,0D,0F]), will be relayed by -+ * any TPMRs but will propagate no further than the nearest S-VLAN component, -+ * C-VLAN component, or MAC Bridge. -+ * -+ * The Nearest Customer Bridge group address (01-80-C2-00-00-00) is an address -+ * that no conformant C-VLAN component, MAC Bridge can forward; however, it is -+ * relayed by TPMR components and S-VLAN components. PDUs using this -+ * destination address, or any of the other addresses that appear in Table 8-1 -+ * but not in either Table 8-2 or Table 8-3 (01-80-C2-00-00-[00,0B,0C,0D,0F]), -+ * will be relayed by TPMR components and S-VLAN components but will propagate -+ * no further than the nearest C-VLAN component or MAC Bridge. -+ * -+ * Because the LLC Entity associated with each Bridge Port is provided via CPU -+ * port, we must not filter these frames but forward them to CPU port. -+ * -+ * In a Bridge, the transmission Port is majorly decided by ingress and egress -+ * rules, FDB, and spanning tree Port State functions of the Forwarding Process. -+ * For link-local frames, only CPU port should be designated as destination port -+ * in the FDB, and the other functions of the Forwarding Process must not -+ * interfere with the decision of the transmission Port. We call this process -+ * trapping frames to CPU port. -+ * -+ * Therefore, on the switch with CPU port architecture, link-local frames must -+ * be trapped to CPU port, and certain link-local frames received by a Port of a -+ * Bridge comprising a TPMR component or an S-VLAN component must be excluded -+ * from it. -+ * -+ * A Bridge of the switch with CPU port architecture cannot comprise a Two-Port -+ * MAC Relay (TPMR) component as a TPMR component supports only a subset of the -+ * functionality of a MAC Bridge. A Bridge comprising two Ports (Management Port -+ * doesn't count) of this architecture will either function as a standard MAC -+ * Bridge or a standard VLAN Bridge. -+ * -+ * Therefore, a Bridge of this architecture can only comprise S-VLAN components, -+ * C-VLAN components, or MAC Bridge components. Since there's no TPMR component, -+ * we don't need to relay PDUs using the destination addresses specified on the -+ * Nearest non-TPMR section, and the proportion of the Nearest Customer Bridge -+ * section where they must be relayed by TPMR components. -+ * -+ * One option to trap link-local frames to CPU port is to add static FDB entries -+ * with CPU port designated as destination port. However, because that -+ * Independent VLAN Learning (IVL) is being used on every VID, each entry only -+ * applies to a single VLAN Identifier (VID). For a Bridge comprising a MAC -+ * Bridge component or a C-VLAN component, there would have to be 16 times 4096 -+ * entries. This switch intellectual property can only hold a maximum of 2048 -+ * entries. Using this option, there also isn't a mechanism to prevent -+ * link-local frames from being discarded when the spanning tree Port State of -+ * the reception Port is discarding. -+ * -+ * The remaining option is to utilise the BPC, RGAC1, RGAC2, RGAC3, and RGAC4 -+ * registers. Whilst this applies to every VID, it doesn't contain all of the -+ * reserved MAC addresses without affecting the remaining Standard Group MAC -+ * Addresses. The REV_UN frame tag utilised using the RGAC4 register covers the -+ * remaining 01-80-C2-00-00-[04,05,06,07,08,09,0A,0B,0C,0D,0F] destination -+ * addresses. It also includes the 01-80-C2-00-00-22 to 01-80-C2-00-00-FF -+ * destination addresses which may be relayed by MAC Bridges or VLAN Bridges. -+ * The latter option provides better but not complete conformance. -+ * -+ * This switch intellectual property also does not provide a mechanism to trap -+ * link-local frames with specific destination addresses to CPU port by Bridge, -+ * to conform to the filtering rules for the distinct Bridge components. -+ * -+ * Therefore, regardless of the type of the Bridge component, link-local frames -+ * with these destination addresses will be trapped to CPU port: -+ * -+ * 01-80-C2-00-00-[00,01,02,03,0E] -+ * -+ * In a Bridge comprising a MAC Bridge component or a C-VLAN component: -+ * -+ * Link-local frames with these destination addresses won't be trapped to CPU -+ * port which won't conform to IEEE Std 802.1Q-2022: -+ * -+ * 01-80-C2-00-00-[04,05,06,07,08,09,0A,0B,0C,0D,0F] -+ * -+ * In a Bridge comprising an S-VLAN component: -+ * -+ * Link-local frames with these destination addresses will be trapped to CPU -+ * port which won't conform to IEEE Std 802.1Q-2022: -+ * -+ * 01-80-C2-00-00-00 -+ * -+ * Link-local frames with these destination addresses won't be trapped to CPU -+ * port which won't conform to IEEE Std 802.1Q-2022: -+ * -+ * 01-80-C2-00-00-[04,05,06,07,08,09,0A] -+ * -+ * To trap link-local frames to CPU port as conformant as this switch -+ * intellectual property can allow, link-local frames are made to be regarded as -+ * Bridge Protocol Data Units (BPDUs). This is because this switch intellectual -+ * property only lets the frames regarded as BPDUs bypass the spanning tree Port -+ * State function of the Forwarding Process. -+ * -+ * The only remaining interference is the ingress rules. When the reception Port -+ * has no PVID assigned on software, VLAN-untagged frames won't be allowed in. -+ * There doesn't seem to be a mechanism on the switch intellectual property to -+ * have link-local frames bypass this function of the Forwarding Process. - */ - static void - mt753x_trap_frames(struct mt7530_priv *priv) -@@ -964,35 +1117,43 @@ mt753x_trap_frames(struct mt7530_priv *p - /* Trap 802.1X PAE frames and BPDUs to the CPU port(s) and egress them - * VLAN-untagged. - */ -- mt7530_rmw(priv, MT753X_BPC, MT753X_PAE_EG_TAG_MASK | -- MT753X_PAE_PORT_FW_MASK | MT753X_BPDU_EG_TAG_MASK | -- MT753X_BPDU_PORT_FW_MASK, -- MT753X_PAE_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | -- MT753X_PAE_PORT_FW(MT753X_BPDU_CPU_ONLY) | -- MT753X_BPDU_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | -- MT753X_BPDU_CPU_ONLY); -+ mt7530_rmw(priv, MT753X_BPC, -+ MT753X_PAE_BPDU_FR | MT753X_PAE_EG_TAG_MASK | -+ MT753X_PAE_PORT_FW_MASK | MT753X_BPDU_EG_TAG_MASK | -+ MT753X_BPDU_PORT_FW_MASK, -+ MT753X_PAE_BPDU_FR | -+ MT753X_PAE_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | -+ MT753X_PAE_PORT_FW(MT753X_BPDU_CPU_ONLY) | -+ MT753X_BPDU_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | -+ MT753X_BPDU_CPU_ONLY); - - /* Trap frames with :01 and :02 MAC DAs to the CPU port(s) and egress - * them VLAN-untagged. - */ -- mt7530_rmw(priv, MT753X_RGAC1, MT753X_R02_EG_TAG_MASK | -- MT753X_R02_PORT_FW_MASK | MT753X_R01_EG_TAG_MASK | -- MT753X_R01_PORT_FW_MASK, -- MT753X_R02_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | -- MT753X_R02_PORT_FW(MT753X_BPDU_CPU_ONLY) | -- MT753X_R01_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | -- MT753X_BPDU_CPU_ONLY); -+ mt7530_rmw(priv, MT753X_RGAC1, -+ MT753X_R02_BPDU_FR | MT753X_R02_EG_TAG_MASK | -+ MT753X_R02_PORT_FW_MASK | MT753X_R01_BPDU_FR | -+ MT753X_R01_EG_TAG_MASK | MT753X_R01_PORT_FW_MASK, -+ MT753X_R02_BPDU_FR | -+ MT753X_R02_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | -+ MT753X_R02_PORT_FW(MT753X_BPDU_CPU_ONLY) | -+ MT753X_R01_BPDU_FR | -+ MT753X_R01_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | -+ MT753X_BPDU_CPU_ONLY); - - /* Trap frames with :03 and :0E MAC DAs to the CPU port(s) and egress - * them VLAN-untagged. - */ -- mt7530_rmw(priv, MT753X_RGAC2, MT753X_R0E_EG_TAG_MASK | -- MT753X_R0E_PORT_FW_MASK | MT753X_R03_EG_TAG_MASK | -- MT753X_R03_PORT_FW_MASK, -- MT753X_R0E_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | -- MT753X_R0E_PORT_FW(MT753X_BPDU_CPU_ONLY) | -- MT753X_R03_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | -- MT753X_BPDU_CPU_ONLY); -+ mt7530_rmw(priv, MT753X_RGAC2, -+ MT753X_R0E_BPDU_FR | MT753X_R0E_EG_TAG_MASK | -+ MT753X_R0E_PORT_FW_MASK | MT753X_R03_BPDU_FR | -+ MT753X_R03_EG_TAG_MASK | MT753X_R03_PORT_FW_MASK, -+ MT753X_R0E_BPDU_FR | -+ MT753X_R0E_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | -+ MT753X_R0E_PORT_FW(MT753X_BPDU_CPU_ONLY) | -+ MT753X_R03_BPDU_FR | -+ MT753X_R03_EG_TAG(MT7530_VLAN_EG_UNTAGGED) | -+ MT753X_BPDU_CPU_ONLY); - } - - static void ---- a/drivers/net/dsa/mt7530.h -+++ b/drivers/net/dsa/mt7530.h -@@ -65,6 +65,7 @@ enum mt753x_id { - - /* Registers for BPDU and PAE frame control*/ - #define MT753X_BPC 0x24 -+#define MT753X_PAE_BPDU_FR BIT(25) - #define MT753X_PAE_EG_TAG_MASK GENMASK(24, 22) - #define MT753X_PAE_EG_TAG(x) FIELD_PREP(MT753X_PAE_EG_TAG_MASK, x) - #define MT753X_PAE_PORT_FW_MASK GENMASK(18, 16) -@@ -75,20 +76,24 @@ enum mt753x_id { - - /* Register for :01 and :02 MAC DA frame control */ - #define MT753X_RGAC1 0x28 -+#define MT753X_R02_BPDU_FR BIT(25) - #define MT753X_R02_EG_TAG_MASK GENMASK(24, 22) - #define MT753X_R02_EG_TAG(x) FIELD_PREP(MT753X_R02_EG_TAG_MASK, x) - #define MT753X_R02_PORT_FW_MASK GENMASK(18, 16) - #define MT753X_R02_PORT_FW(x) FIELD_PREP(MT753X_R02_PORT_FW_MASK, x) -+#define MT753X_R01_BPDU_FR BIT(9) - #define MT753X_R01_EG_TAG_MASK GENMASK(8, 6) - #define MT753X_R01_EG_TAG(x) FIELD_PREP(MT753X_R01_EG_TAG_MASK, x) - #define MT753X_R01_PORT_FW_MASK GENMASK(2, 0) - - /* Register for :03 and :0E MAC DA frame control */ - #define MT753X_RGAC2 0x2c -+#define MT753X_R0E_BPDU_FR BIT(25) - #define MT753X_R0E_EG_TAG_MASK GENMASK(24, 22) - #define MT753X_R0E_EG_TAG(x) FIELD_PREP(MT753X_R0E_EG_TAG_MASK, x) - #define MT753X_R0E_PORT_FW_MASK GENMASK(18, 16) - #define MT753X_R0E_PORT_FW(x) FIELD_PREP(MT753X_R0E_PORT_FW_MASK, x) -+#define MT753X_R03_BPDU_FR BIT(9) - #define MT753X_R03_EG_TAG_MASK GENMASK(8, 6) - #define MT753X_R03_EG_TAG(x) FIELD_PREP(MT753X_R03_EG_TAG_MASK, x) - #define MT753X_R03_PORT_FW_MASK GENMASK(2, 0) diff --git a/target/linux/generic/pending-6.6/795-net-dsa-mt7530-fix-enabling-EEE-on-MT7531-switch-on-.patch b/target/linux/generic/pending-6.6/795-net-dsa-mt7530-fix-enabling-EEE-on-MT7531-switch-on-.patch deleted file mode 100644 index 9a4d4a918a80..000000000000 --- a/target/linux/generic/pending-6.6/795-net-dsa-mt7530-fix-enabling-EEE-on-MT7531-switch-on-.patch +++ /dev/null @@ -1,92 +0,0 @@ -From ef972fc9f5743da589ce9546dd565d6c56e679b8 Mon Sep 17 00:00:00 2001 -From: =?UTF-8?q?Ar=C4=B1n=C3=A7=20=C3=9CNAL?= -Date: Mon, 8 Apr 2024 10:08:53 +0300 -Subject: [PATCH 1/2] net: dsa: mt7530: fix enabling EEE on MT7531 switch on - all boards -MIME-Version: 1.0 -Content-Type: text/plain; charset=UTF-8 -Content-Transfer-Encoding: 8bit - -The commit 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE features") -brought EEE support but did not enable EEE on MT7531 switch MACs. EEE is -enabled on MT7531 switch MACs by pulling the LAN2LED0 pin low on the board -(bootstrapping), unsetting the EEE_DIS bit on the trap register, or setting -the internal EEE switch bit on the CORE_PLL_GROUP4 register. Thanks to -SkyLake Huang (黃啟澤) from MediaTek for providing information on the -internal EEE switch bit. - -There are existing boards that were not designed to pull the pin low. -Because of that, the EEE status currently depends on the board design. - -The EEE_DIS bit on the trap pertains to the LAN2LED0 pin which is usually -used to control an LED. Once the bit is unset, the pin will be low. That -will make the active low LED turn on. The pin is controlled by the switch -PHY. It seems that the PHY controls the pin in the way that it inverts the -pin state. That means depending on the wiring of the LED connected to -LAN2LED0 on the board, the LED may be on without an active link. - -To not cause this unwanted behaviour whilst enabling EEE on all boards, set -the internal EEE switch bit on the CORE_PLL_GROUP4 register. - -My testing on MT7531 shows a certain amount of traffic loss when EEE is -enabled. That said, I haven't come across a board that enables EEE. So -enable EEE on the switch MACs but disable EEE advertisement on the switch -PHYs. This way, we don't change the behaviour of the majority of the boards -that have this switch. The mediatek-ge PHY driver already disables EEE -advertisement on the switch PHYs but my testing shows that it is somehow -enabled afterwards. Disabling EEE advertisement before the PHY driver -initialises keeps it off. - -With this change, EEE can now be enabled using ethtool. - -Fixes: 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE features") -Reviewed-by: Florian Fainelli -Signed-off-by: Arınç ÜNAL ---- - drivers/net/dsa/mt7530.c | 17 ++++++++++++----- - drivers/net/dsa/mt7530.h | 1 + - 2 files changed, 13 insertions(+), 5 deletions(-) - ---- a/drivers/net/dsa/mt7530.c -+++ b/drivers/net/dsa/mt7530.c -@@ -2666,18 +2666,25 @@ mt7531_setup(struct dsa_switch *ds) - mt7530_rmw(priv, MT7531_GPIO_MODE0, MT7531_GPIO0_MASK, - MT7531_GPIO0_INTERRUPT); - -- /* Enable PHY core PLL, since phy_device has not yet been created -- * provided for phy_[read,write]_mmd_indirect is called, we provide -- * our own mt7531_ind_mmd_phy_[read,write] to complete this -- * function. -+ /* Enable Energy-Efficient Ethernet (EEE) and PHY core PLL, since -+ * phy_device has not yet been created provided for -+ * phy_[read,write]_mmd_indirect is called, we provide our own -+ * mt7531_ind_mmd_phy_[read,write] to complete this function. - */ - val = mt7531_ind_c45_phy_read(priv, MT753X_CTRL_PHY_ADDR, - MDIO_MMD_VEND2, CORE_PLL_GROUP4); -- val |= MT7531_PHY_PLL_BYPASS_MODE; -+ val |= MT7531_RG_SYSPLL_DMY2 | MT7531_PHY_PLL_BYPASS_MODE; - val &= ~MT7531_PHY_PLL_OFF; - mt7531_ind_c45_phy_write(priv, MT753X_CTRL_PHY_ADDR, MDIO_MMD_VEND2, - CORE_PLL_GROUP4, val); - -+ /* Disable EEE advertisement on the switch PHYs. */ -+ for (i = MT753X_CTRL_PHY_ADDR; -+ i < MT753X_CTRL_PHY_ADDR + MT7530_NUM_PHYS; i++) { -+ mt7531_ind_c45_phy_write(priv, i, MDIO_MMD_AN, MDIO_AN_EEE_ADV, -+ 0); -+ } -+ - mt7531_setup_common(ds); - - /* Setup VLAN ID 0 for VLAN-unaware bridges */ ---- a/drivers/net/dsa/mt7530.h -+++ b/drivers/net/dsa/mt7530.h -@@ -621,6 +621,7 @@ enum mt7531_clk_skew { - #define RG_SYSPLL_DDSFBK_EN BIT(12) - #define RG_SYSPLL_BIAS_EN BIT(11) - #define RG_SYSPLL_BIAS_LPF_EN BIT(10) -+#define MT7531_RG_SYSPLL_DMY2 BIT(6) - #define MT7531_PHY_PLL_OFF BIT(5) - #define MT7531_PHY_PLL_BYPASS_MODE BIT(4) -