From nobody Mon Sep 28 09:59:44 2026 Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CCB6A3749F5 for ; Mon, 24 Aug 2026 02:41:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787539292; cv=none; b=g+kiVuhPxPs46pH3WgnopcrYjbBhFLwsFuXYjisbuwba9QteAT1YqMgd5xHpQsoc+3uxj3mFVUGx+HUFhsSPgoihvi4C5EZYN9GGYrobjqJODWB/8TwyZ1KGEoATrcrjgilktDnaCLbp7VBquQwtktx9tLxMg79x1kN0i7p0k/w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787539292; c=relaxed/simple; bh=SDSa7BtdilxKJxAuJe9gwz7nnNXSQ/tSrnRfRU7KXMU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NLCH5YtbO2oCwMiSpMlptn/Qqeo5YRth85U9MS7+sYcW17a8YNQEMR21s5vvkwLNttmK4TXnxJ3aYEXgp9chjsqw9Npg6J9hViCgHhmSL467yAQLqsxdeGAR+eU3CHCB8XvrDSjiWXaBRLrLhwPbaDqE2pAuyp/6IKIuED5GROQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=lex.la; spf=pass smtp.mailfrom=lex.la; dkim=pass (2048-bit key) header.d=lex.la header.i=@lex.la header.b=YD6OZT3k; arc=none smtp.client-ip=209.85.218.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=lex.la Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lex.la Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lex.la header.i=@lex.la header.b="YD6OZT3k" Received: by mail-ej1-f54.google.com with SMTP id a640c23a62f3a-c2055f5a993so330336266b.2 for ; Sun, 23 Aug 2026 19:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lex.la; s=google; t=1787539286; x=1788144086; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=sG09oMeCLLGrjaF3KS0dxUwY4QMRP5eQuHdTPgxNNbs=; b=YD6OZT3kdeNx4E3mVj7DC17PiR+Fsiv5dCDJYaqHrWVUNyiXyiyywCo0PdJuFa4Pn9 OSgTCaLx+YV8PmPwRUaAfUpM6ETFbEY1GL4knVHn2lyzHiTOTU3Xd/U+NrAJ6P4eJ1AW gZXVtBmkkLvBBfIyp6ZWGc/TsbBTr/1/7BbsuJACGGSEXJ5bCCcBKdgVH6x1RFb6JA6K aJQ835Dg34IjMuooiHZk69IKCve78bHLmnSxZip+4bZ3oHnU7hLTkDCoys0sCZtnH5/k 2+ID1wRAL5oIr076hbep6pZQhGiZy4N1F+NhFE0knQgaMyiZdaBMCo/38Zh/mq+m/VrM XzjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787539286; x=1788144086; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=sG09oMeCLLGrjaF3KS0dxUwY4QMRP5eQuHdTPgxNNbs=; b=JedGmXlpA28sEt/qUWthVbumPYY6E1gPKE2erl/5Wov/9TfI++1qOm6FsiXw1EP0qP xJ2at+SIOSTdWLGzVg0wxIZGHsyjC1R6pQONz7zJPqCkrwuEhRnD3bbtDrTuFkjx94Do 8fTvJbAZ82ohF6e7QIz5NA9WvSTlM1ORmxlVMvqsdLrYMGsOcFRyutmW7sAQOxjnMeXd 9dyQm0yX1rRJJaT9NL3yi8LWtw2SQ8Kmo56cgDC23biuhDVmVGk9BfK+9nfimkNs/4kH eoN+sHAhUCKoh5/NLwFqEGGwdI5VWBokL0IxfuyOU5EtksEg+K3vHYxnvMBNO8mUqoC6 LoEQ== X-Forwarded-Encrypted: i=1; AHgh+RoW3hR90U76nVk4yw0cebwoSSJkDXY58PYN0102WNcr74wVuAD83SfmpYEkf3srAw1fScSVtn+XACO6PZw=@vger.kernel.org X-Gm-Message-State: AFuF++mwRwyjBVu/fuvlDRoM1AWcvUA/9XSbHXZhme8vsT3iV/js0CBg ZKdKU+oCNTmIGWZbBlWiJhJQDWbi9tLTmuEeUftD9xYpUL1dYlp9miimBdIAtT0mffA= X-Gm-Gg: AR+sD13JraZ9dE9fa8+xGufZPEb06lvhTvUYiAPO0fTNP4XRQBXMRtCO4of6Uei4lo0 SCJl/sHteRmqSHu1Whdsyq6CAnwFYHsOcev1R6yhEhcANoGikeB/n132B0DzQEkD6TyxU3y94rY kvsHJpyYprIAeZVSkpFFTCEiuzVk0GUmwwzYMQr+kZGDuDL2F/5sxkhLhiaSYFi/t32UXj7561U IC1YJaCHNMxXEwzmGJFg5sjwtfTfO8rPo1N0WRwMxcYpRp2OUhr6EcaRgHdB5v0malZ0lb+Y29s KzNaPFOotA8lav/6Oa+b8FYPh4kL480502xQf00SDoDZPX51T6bNxmG/a4tEWPz/DIrsZlvNPZw pa5vXb5vsQbHxcOiRCIM1Xis7Yyu+k007AGKUJfPHIZ/HfZuc1bppaq+NgH+aYy427g14mVyGhk oUzQOz/ekbMFbK2UYRJEnWs3kGg9XWZ6JqXdmrQKIWwbcEx38/QFHrtpxe X-Received: by 2002:a17:907:d408:b0:c21:96e8:578d with SMTP id a640c23a62f3a-c246a684291mr2660691566b.15.1787539285591; Sun, 23 Aug 2026 19:41:25 -0700 (PDT) Received: from ownbook ([195.181.160.194]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c249686e37bsm949008466b.55.2026.08.23.19.41.22 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sun, 23 Aug 2026 19:41:25 -0700 (PDT) From: Aleksei Sviridkin To: "Chester A . Unal" , Daniel Golle , Andrew Lunn , Vladimir Oltean , Felix Fietkau , Lorenzo Bianconi , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org Cc: Russell King , Qingfang Deng , Matthias Brugger , AngeloGioacchino Del Regno , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Aleksei Sviridkin Subject: [PATCH net v2 1/2] net: dsa: mt7530: populate lpi_interfaces to fix EEE support Date: Mon, 24 Aug 2026 05:41:16 +0300 Message-ID: <20260824024117.46154-2-f@lex.la> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260824024117.46154-1-f@lex.la> References: <20260824024117.46154-1-f@lex.la> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" mt753x_phylink_get_caps() fills in lpi_capabilities and lpi_timer_default but never lpi_interfaces, so phylink treats the MAC as not supporting EEE: ethtool reports "Not supported" and phy_disable_eee() keeps userspace locked out. That undoes what commit 06dfcd4098cf ("net: dsa: mt7530: fix enabling EEE on MT7531 switch on all boards") arranged: EEE off by default, but enableable with ethtool. Copy the supported interfaces into lpi_interfaces after mac_port_get_caps() has populated them, and leave the speeds above 1 Gbps out for now: drop 2500BASE-X from the copy, drop MAC_2500FD from lpi_capabilities, and skip ports that support neither 100 Mbps nor 1 Gbps. PMCR folds SPEED_2500 and SPEED_10000 onto PMCR_FORCE_SPEED_1000, so PMCR_FORCE_EEE1G is what would govern LPI on those links, and it is unvalidated rather than unsupported: MediaTek's SDK driver sets the EEE force bits for 100 Mbps and 1 Gbps link speed only, EEE signalling on 2500BASE-X is outside 802.3, and the 1 us unit of the wakeup timers is undocumented with the port clock at 2.5 times the rate. Narrowing lpi_capabilities alone would not do it, since it gates on the media speed a rate matching PHY reports rather than on the speed the MAC runs at. On MT7988, EN7581 and AN7583 port 6 is 10 Gbps only and shares PHY_INTERFACE_MODE_INTERNAL with the user ports, so the interface mask alone cannot tell them apart. LPI stays off until userspace enables it. The EEE advertisement of a PHY that advertises it out of reset does come back, since phylink stops force-clearing it. MT7531's internal PHYs keep the advertisement mt7531_setup() zeroed, and EN7528 keeps both bitmaps empty, so EEE stays fully off there. Fixes: 9cf21773f535 ("net: dsa: mt7530: convert to phylink managed EEE") Signed-off-by: Aleksei Sviridkin --- Two pre-existing things this patch makes live, neither addressed here: - The unit of LPI_THRESH is still unspecified, as the comment above lpi_timer_default says. With EEE reachable again, ethtool reports that raw value as microseconds and writes userspace values back unconverted, while mtk_eth_soc treats a structurally identical field as milliseconds (DIV_ROUND_UP(timer, 1000)). Reading the default back reproduces the same raw value whatever the unit is, but a timer set from userspace in microseconds would be off by 1000 if the field is in milliseconds. On an MT7531 board ethtool now reports 30 for a switch port, the raw LPI_THRESH field, against 1000 for the SoC MAC, which is a driver constant already in microseconds; whether the hardware means 30 microseconds is exactly the open question. Does anyone have the datasheet answer? - mt753x_phylink_mac_enable_tx_lpi() sets the PMCR force-EEE bits without checking the resolved speed or interface, relying entirely on phylink never calling it above 1 Gbps. A check there would make the driver robust independently of lpi_interfaces being right; if that check is ever sent, it will warn loudly. On leaving the higher speeds out: the absence of 2.5 Gbps EEE force bits in PMCR is not the argument, since the same reasoning applied to the speed field would say the switch cannot do 2.5 Gbps at all. The masks say nobody has validated it, not that the hardware refuses. Doing that here rather than in a separate patch changes nothing observable: while lpi_interfaces was empty, lpi_capabilities never reached phy->advertising_eee. If PMCR_FORCE_EEE1G does work on the overclocked link, a rate matched EN8811H port is exactly the setup that would benefit, so this is worth an experiment later. drivers/net/dsa/mt7530.c | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-) diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c index 2b7be091c056..4ed6218df64b 100644 --- a/drivers/net/dsa/mt7530.c +++ b/drivers/net/dsa/mt7530.c @@ -3172,23 +3172,37 @@ static void mt753x_phylink_get_caps(struct dsa_swit= ch *ds, int port, =20 config->mac_capabilities =3D MAC_ASYM_PAUSE | MAC_SYM_PAUSE; =20 + priv->info->mac_port_get_caps(ds, port, config); + /* The EN7528 GPHYs report EEE capability, but negotiating EEE with * common link partners (e.g. Realtek GbE NICs) results in an unstable * link with dropped frames. Leave the LPI capabilities empty so that * phylink disables EEE on these PHYs and refuses to enable it from - * userspace. + * userspace. Ports that run at neither 100 Mbps nor 1 Gbps are left + * empty too, since LPI above 1 Gbps is unvalidated. */ - if (priv->id !=3D ID_EN7528) { + if (priv->id !=3D ID_EN7528 && + config->mac_capabilities & (MAC_100FD | MAC_1000FD)) { u32 eeecr =3D mt7530_read(priv, MT753X_PMEEECR_P(port)); =20 - config->lpi_capabilities =3D MAC_100FD | MAC_1000FD | MAC_2500FD; + /* PMCR folds SPEED_2500 and SPEED_10000 onto + * PMCR_FORCE_SPEED_1000, so LPI above 1 Gbps would be + * governed by PMCR_FORCE_EEE1G and is unvalidated rather than + * unsupported. Leave it out of both bitmaps: lpi_capabilities + * gates on the media speed a rate matching PHY reports, not + * on the speed the MAC runs at. + */ + config->lpi_capabilities =3D MAC_100FD | MAC_1000FD; + phy_interface_copy(config->lpi_interfaces, + config->supported_interfaces); + __clear_bit(PHY_INTERFACE_MODE_2500BASEX, + config->lpi_interfaces); + /* tx_lpi_timer should be in microseconds. The time units for * LPI threshold are unspecified. */ config->lpi_timer_default =3D FIELD_GET(LPI_THRESH_MASK, eeecr); } - - priv->info->mac_port_get_caps(ds, port, config); } =20 static int mt753x_pcs_validate(struct phylink_pcs *pcs, --=20 2.55.0 From nobody Mon Sep 28 09:59:44 2026 Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DF34EDF76 for ; Mon, 24 Aug 2026 02:41:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787539295; cv=none; b=A07gfTJaUXRAkivJgdtnl8xKjjZRX9GUNZWzaCtfJ9Yk+4tYwZCHGrda2qKSW/cvKKZV+5TczMetiII6hU52jr4WHPB6gLeYX2zJqQa3y4hFzqxmY2PJ08oeMeFw2JHU1ex9TBM6K+g8jcSIoVnXBad+UU+joISgapcyohf0VWA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787539295; c=relaxed/simple; bh=AD9+/6KWGvFpcCoDcfBCRac/d4Y11iTlGJwO4GZJrJI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YS73CqyIYdFqq+if8WCcRQQqZh5JAEZcwx5G0btNGuixEJ9F6pZGvljrZ3qtanT40EQFWIXAT7ibpDiqhG6PjN3MDwCsHBeJ8OtVMfpqvSqK8qIy2ifiQhREx6XxIuVQbrw2n24y+dOY7aGp3WIMe79c/Byb5vUTBnvwAuqofcw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=lex.la; spf=pass smtp.mailfrom=lex.la; dkim=pass (2048-bit key) header.d=lex.la header.i=@lex.la header.b=STcJjMd+; arc=none smtp.client-ip=209.85.208.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=lex.la Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lex.la Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lex.la header.i=@lex.la header.b="STcJjMd+" Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-6a0c8283146so5027210a12.0 for ; Sun, 23 Aug 2026 19:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lex.la; s=google; t=1787539288; x=1788144088; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=eff4/RO9BXDKGgT0WoHgozDOguCB0zRc8wyBEOOYuWg=; b=STcJjMd+G5x1JY8u5EslApqPneZ+meMBcIZg+pI0MXkAITjn5aKI169Q75jTi0zbW3 X4+1EaEKMrH6Gc7E6ZWhIuQwk3ze4JHztUvggWKdG9RJrMhlyNm0mLtK9NQ6cGGWaz6M ztnpHVKX8FnkfHFp3hCxQp0T9O4mlDq3+ozg9H/Y/8OZ8rOX1TtUYBrEztHk7kgtbV3p 95gbL9OCL9Ei75rIEeZIDTxgKnSL3EFRSnVHwfJGeA9QzeDnCabdpRe0kZC/gqZPpC2v sj97D56AJN2J5wZxsqdklklkaYK5tU4BAq1bRzPWk9cCIqsOgGN+UvUBqEdVLw0zWmQh uNLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787539288; x=1788144088; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=eff4/RO9BXDKGgT0WoHgozDOguCB0zRc8wyBEOOYuWg=; b=cjS/Nb89/XzMO2JoXN1IsR/LTlwulfbY/kfqw9gKdlkk63KpM8EqyERlUof086JPHC MnbObkQtyaUpy5NeJpSc4a4S3FplqGzIPrxOKQHIz5Cg5yERVoWfZU6pu3SzMaF+7Jbz 7C0syrAwM0wbrD8IAA5sdFECpCq4kKORqihgE4YaY3hdFSF2KpmHSK7F0/xu14K3rg86 rJtX8w+hCmqRNmshJITg9DMixFqXOL04LYXdXyjlL5du8U/PIQNF2CHhgxsnVYkufCNL NalOsd2+fT8hcc/LZUGfmyihbFpLkovMrGeTfsgC4TdIrgqQ1QyjFKiYRxU/zVNG5D1F xHZQ== X-Forwarded-Encrypted: i=1; AHgh+Ro1kcgo9d5A+PuvKz5yRAnrFJqeQfaw2Ouc0porgh0e8xbNsRbsmsiRcIoHC6xbYwwfCBOT9jSrJCIVkxU=@vger.kernel.org X-Gm-Message-State: AFuF++mrwSeTDPY09Ys+hmcPOMMxpoPdSrN1OfHMMfopifu2rCLkp/tX YVkzlxocbJr51II/o5bKFHKMm9EXQU4Fbz6MuhcLkytktAGX6YDWhUHEoQPSd0RAAVQ= X-Gm-Gg: AR+sD12p5HAutCsFnb1Hp673MblpqDWEDRgJOs1Atgqpkq+wQKrzInXmwgS36LVVDsw uFdDdvo18SrPYFBN78cbdmSxd7y3pmjQhjHId/Z/OfHFgTawICTAkVnuNn9h0aInO0AKIIB4YqS AAibaFQunxITvTq9h/s4Zr/Ppe1YFK239aLAUkTUa2Q8jI2cd+UmY8OqyVQRjJslbRktlbSd9io UF+GVegjIuOwHist/h6z7vI74IKUTwSJaQKJVb6ECN3DP5uXGAi5zmupgBXWDj/C4N0L5iK13WW XQ5Bxjez+hTnOw6NglvkSTcbtk1zZidCXmqn+hlsMldmQEGVfwnm8M9teqmC4fqu7VMBOs1g0e6 BjjAnpHJJ8fZVUBjztIFAtA5cmtn18eEPnhHhDA0ZujwiPYdyKXE9FUpa8ToimD7Jrp3aKh9FmU l44ABBkBTiXx6pyJCx2mKdhT/sO4F5WrAcfnGX3enxuJBOY94fEOj1e1n0 X-Received: by 2002:a17:906:fd83:b0:c12:5a0e:3e0 with SMTP id a640c23a62f3a-c246a651b90mr2593036066b.19.1787539288568; Sun, 23 Aug 2026 19:41:28 -0700 (PDT) Received: from ownbook ([195.181.160.194]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c249686e37bsm949008466b.55.2026.08.23.19.41.25 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sun, 23 Aug 2026 19:41:28 -0700 (PDT) From: Aleksei Sviridkin To: "Chester A . Unal" , Daniel Golle , Andrew Lunn , Vladimir Oltean , Felix Fietkau , Lorenzo Bianconi , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org Cc: Russell King , Qingfang Deng , Matthias Brugger , AngeloGioacchino Del Regno , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Aleksei Sviridkin Subject: [PATCH net v2 2/2] net: ethernet: mtk_eth_soc: populate lpi_interfaces to fix EEE support Date: Mon, 24 Aug 2026 05:41:17 +0300 Message-ID: <20260824024117.46154-3-f@lex.la> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260824024117.46154-1-f@lex.la> References: <20260824024117.46154-1-f@lex.la> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" mtk_add_mac() fills in lpi_capabilities and lpi_timer_default but never lpi_interfaces, so phylink treats every MAC that uses mtk_phylink_ops as not supporting EEE: ethtool reports "Not supported" and phy_disable_eee() keeps userspace locked out. MT7628 is unaffected, as rt5350_phylink_ops has no tx_lpi methods. Copy the supported interfaces into lpi_interfaces once the SoC specific fixups have finished changing them, and leave 2.5 Gbps out for now: drop 2500BASE-X from the copy and MAC_2500FD from lpi_capabilities. MAC_MCR folds SPEED_2500 onto MAC_MCR_SPEED_1000, so MAC_MCR_EEE1G is what would govern LPI on such a link, and it is unvalidated rather than unsupported: MediaTek's SDK driver sets the EEE force bits for 100 Mbps and 1 Gbps link speed only, EEE signalling on 2500BASE-X is outside 802.3, and the 1 us unit of the wakeup timers is undocumented with the port clock at 2.5 times the rate. Narrowing lpi_capabilities alone would not do it, since it gates on the media speed a rate matching PHY reports rather than on the speed the MAC runs at. Drop the xGMII modes too, which mtk_mac_enable_tx_lpi() refuses outright and which on netsys v3 include the mode of MT7988's built-in 2.5G PHY. LPI stays off until userspace enables it. The EEE advertisement of a PHY that advertises it out of reset does come back, since phylink stops force-clearing it. Fixes: 952d7325362f ("net: ethernet: mediatek: add EEE support") Signed-off-by: Aleksei Sviridkin --- On leaving 2.5 Gbps out: the absence of 2.5 Gbps EEE force bits in MAC_MCR is not the argument, since the same reasoning applied to the speed field would say the MAC cannot do 2.5 Gbps at all - 2500BASE-X here is 1000BASE-X at 2.5 times the clock, and the MAC does not know the difference. MAC_2500FD was deliberate in the original EEE submission [1], which set MAC_MCR_EEE1G for SPEED_2500 and SPEED_1000 alike. The masks say nobody has validated it, not that the hardware refuses. On the netsys v3 switch MAC the xGMII filter empties lpi_interfaces outright, as PHY_INTERFACE_MODE_INTERNAL is the only interface it supports. It is a fixed link port with no PHY, so phylink had no EEE to manage there before this patch either. Pre-existing, made live by this patch and not addressed here: mtk_mac_enable_tx_lpi() programs MT7531's reset wakeup times (17 for 1 Gbps, 36 for 100 Mbps) whenever it runs, as its own comment says, so they now apply to every SoC driven by mtk_phylink_ops once a user enables EEE on an eligible interface. Those values do not appear to have been confirmed for MT7981, MT7986 or MT7988. [1] https://lore.kernel.org/all/20250210125246.1950142-1-dqfext@gmail.com/ drivers/net/ethernet/mediatek/mtk_eth_soc.c | 22 ++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethe= rnet/mediatek/mtk_eth_soc.c index be3bd025c41a..37a831f73da6 100644 --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c @@ -4828,7 +4828,7 @@ static int mtk_add_mac(struct mtk_eth *eth, struct de= vice_node *np) phy_interface_t phy_mode; struct phylink *phylink; struct mtk_mac *mac; - int id, err; + int id, err, i; int txqs =3D 1; u32 val; =20 @@ -4907,8 +4907,11 @@ static int mtk_add_mac(struct mtk_eth *eth, struct d= evice_node *np) mac->phylink_config.type =3D PHYLINK_NETDEV; mac->phylink_config.mac_capabilities =3D MAC_ASYM_PAUSE | MAC_SYM_PAUSE | MAC_10 | MAC_100 | MAC_1000 | MAC_2500FD; - mac->phylink_config.lpi_capabilities =3D MAC_100FD | MAC_1000FD | - MAC_2500FD; + /* MAC_MCR folds SPEED_2500 onto MAC_MCR_SPEED_1000, so LPI above + * 1 Gbps would be governed by MAC_MCR_EEE1G and is unvalidated + * rather than unsupported. + */ + mac->phylink_config.lpi_capabilities =3D MAC_100FD | MAC_1000FD; mac->phylink_config.lpi_timer_default =3D 1000; =20 /* MT7623 gmac0 is now missing its speed-specific PLL configuration @@ -4966,6 +4969,19 @@ static int mtk_add_mac(struct mtk_eth *eth, struct d= evice_node *np) __set_bit(PHY_INTERFACE_MODE_INTERNAL, mac->phylink_config.supported_interfaces); =20 + phy_interface_copy(mac->phylink_config.lpi_interfaces, + mac->phylink_config.supported_interfaces); + + /* The MAC side of 2500BASE-X is never below 2.5 Gbps, not even when + * a rate matching PHY drops the media to 1 Gbps, and + * mtk_mac_enable_tx_lpi() refuses the xGMII modes outright. + */ + __clear_bit(PHY_INTERFACE_MODE_2500BASEX, + mac->phylink_config.lpi_interfaces); + for (i =3D 0; i < PHY_INTERFACE_MODE_MAX; i++) + if (mtk_interface_mode_is_xgmii(eth, i)) + __clear_bit(i, mac->phylink_config.lpi_interfaces); + phylink =3D phylink_create(&mac->phylink_config, of_fwnode_handle(mac->of_node), phy_mode, mac_ops); --=20 2.55.0