>From 2b4d48c93d317cccafc8128e33f18fab244d5bce Mon Sep 17 00:00:00 2001 From: Vladimir Oltean Date: Mon, 4 Aug 2025 11:15:26 +0300 Subject: [PATCH] net: dpaa: fman_memac: complete phylink support with 2500base-x The DPAA phylink conversion in the following commits partially developed code for handling the 2500base-x host interface mode (called "2.5G SGMII" in LS1043A/LS1046A reference manuals). - 0fc83bd79589 ("net: fman: memac: Add serdes support") - 5d93cfcf7360 ("net: dpaa: Convert to phylink") In principle, having phy-interface-mode = "2500base-x" and a pcsphy-handle (unnamed or with pcs-handle-names = "sgmii") in the MAC device tree node results in PHY_INTERFACE_MODE_2500BASEX being set in phylink_config :: supported_interfaces, but this isn't sufficient. Because memac_select_pcs() returns no PCS for PHY_INTERFACE_MODE_2500BASEX, the Lynx PCS code never engages. There's a chance the PCS driver doesn't have any configuration to change for 2500base-x fixed-link (based on bootloader pre-initialization), but there's an even higher chance that this is not the case, and the PCS remains misconfigured. More importantly, memac_if_mode() does not handle PHY_INTERFACE_MODE_2500BASEX, and it should be telling the mEMAC to configure itself in GMII mode (which is upclocked by the PCS). Currently it prints a WARN_ON() and returns zero, aka IF_MODE_10G (incorrect). The additional case statement in memac_prepare() for calling phy_set_mode_ext() does not make any difference, because there is no generic PHY driver for the Lynx 10G SerDes from LS1043A/LS1046A. But we add it nonetheless, for consistency. Regarding the question "did 2500base-x ever work with the FMan mEMAC mainline code prior to the phylink conversion?" - the answer is more nuanced. For context, the previous phylib-based implementation was unable to describe the fixed-link speed as 2500, because the software PHY implementation is limited to 1G. However, improperly describing the link as an sgmii fixed-link with speed = <1000> would have resulted in a functional 2.5G speed, because there is no other difference than the SerDes lane clock net frequency (3.125 GHz for 2500base-x) - all the other higher-level settings are the same, and the SerDes lane frequency is currently handled by the RCW. But this hack cannot be extended towards a phylib PHY such as Aquantia operating in OCSGMII, because the latter requires phy-mode = "2500base-x", which the mEMAC driver did not support prior to the phylink conversion. So I do not really consider this a regression, just completing support for a missing feature. Signed-off-by: Vladimir Oltean --- drivers/net/ethernet/freescale/fman/fman_memac.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/freescale/fman/fman_memac.c b/drivers/net/ethernet/freescale/fman/fman_memac.c index 0291093f2e4e..b3e25234512e 100644 --- a/drivers/net/ethernet/freescale/fman/fman_memac.c +++ b/drivers/net/ethernet/freescale/fman/fman_memac.c @@ -649,6 +649,7 @@ static u32 memac_if_mode(phy_interface_t interface) return IF_MODE_GMII | IF_MODE_RGMII; case PHY_INTERFACE_MODE_SGMII: case PHY_INTERFACE_MODE_1000BASEX: + case PHY_INTERFACE_MODE_2500BASEX: case PHY_INTERFACE_MODE_QSGMII: return IF_MODE_GMII; case PHY_INTERFACE_MODE_10GBASER: @@ -667,6 +668,7 @@ static struct phylink_pcs *memac_select_pcs(struct phylink_config *config, switch (iface) { case PHY_INTERFACE_MODE_SGMII: case PHY_INTERFACE_MODE_1000BASEX: + case PHY_INTERFACE_MODE_2500BASEX: return memac->sgmii_pcs; case PHY_INTERFACE_MODE_QSGMII: return memac->qsgmii_pcs; @@ -685,6 +687,7 @@ static int memac_prepare(struct phylink_config *config, unsigned int mode, switch (iface) { case PHY_INTERFACE_MODE_SGMII: case PHY_INTERFACE_MODE_1000BASEX: + case PHY_INTERFACE_MODE_2500BASEX: case PHY_INTERFACE_MODE_QSGMII: case PHY_INTERFACE_MODE_10GBASER: return phy_set_mode_ext(memac->serdes, PHY_MODE_ETHERNET, -- 2.43.0