From nobody Mon Sep 28 10:44:09 2026 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) (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 E6EA717993 for ; Sat, 22 Aug 2026 19:52:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.43 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787428380; cv=none; b=L2rRZ9T9VoEwtdOtFjMjNq5iUWXOlmarvZtlKQ9SaSjZp8oLHvs5lHRKNLnemCpYz/7glvOhQ74XJSBE5bjMA1x225+kclP1fW3wKDN9Te9pe1zhtXvbjJfbt+xOG9vQh/rVhmiwUR+Tez8c84IYx2wnNjXzz/DRcqhbpJ3qvOM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787428380; c=relaxed/simple; bh=YgHewjlUllC1H8m77gkdT4/7soHY/AfMrWWgayYqSio=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PNer2X4eCnawNK587K3Gti/KyCnMgHREiNVArVkmuYqIU4Rfby3naT3bpUfYzPNwQZh7aGgJnCearOg/QlyOgw/R1yKSoJnIk+/o7uS+o1coCYq/3F9D2HwDjkBz4xGK6Ql7mRbneaUH2pRletaDY91m79A8OG5XpUWUR3Cypqs= 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=OP9nwC2W; arc=none smtp.client-ip=209.85.218.43 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="OP9nwC2W" Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-c2022323c37so337337766b.0 for ; Sat, 22 Aug 2026 12:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lex.la; s=google; t=1787428377; x=1788033177; 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=H2c7J7LZN/1f9QeAHF6h+0OR2xOM+K9B3aoUShYmicA=; b=OP9nwC2WGJB99bNgaHCS8OIws09c7IM+6aX7P4/O87esoq1+24tiLmOYJkcbvE+wji ABZo7ZSDrMQ1D0mjplkd7iDzK3Np3l4pOqsMk+OZwk3MR+jGdyhs54RACknLO81YgqZR p6JfX9jN+O1h4EgG14G1tiyVJMtRIl3NuOG12Au2Fn0mZEug/NbKVWhAATeITxW0HS8m NmH3+nyIuH5AZJOZZ66my+kC+qw7wLO0+Z1XqUxTPjYqTdyFiQs8Wcm4w6dEC/il8jyx yYS3+TJawWCsVupRcVJN3wSdegv+RNPH1jnMLr955BtXeaQGK7nSc/lWIgQWlFVuYmhM zvjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787428377; x=1788033177; 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=H2c7J7LZN/1f9QeAHF6h+0OR2xOM+K9B3aoUShYmicA=; b=dVfoyZDQnX4EKYl6wF9n6W6kKgfLNwASzuHtmOvF9NySw89TkIItkTxa7kRXC9IcFb DeX9Xg2IFu2o+QLTg9c+LYr09iaD0RYTkXkHG9EbmxxEJd+XRMAEBCRfcrCn6liaUqvW FEj31Cm/2127LoDpSPNR8kMq4liPkKCgvl27KLF6EWSByKhMigsjuv0hI6DebXQz211L ZCbHaU5KqA3uopkkijPE29DVvqujD5TW4Su81iqPJmv0DQ9c6h85KKXAH/kiKv1J5g8g FPqd12uX4l+FvVCxvWQ2b3IJsFbzus8lKcjv0S+0kF9cX1gEAHVKlz+XtidxQmlmVTf2 Cbfg== X-Forwarded-Encrypted: i=1; AHgh+RrxDxt7n1LkDZD4oF7a6DZ6XOwkaMpjiNWfkU2bvngz2RCTBjcQ0IQKBnz/npCNxXjVNxFdGhKz8B5SjWE=@vger.kernel.org X-Gm-Message-State: AFuF++mX5tP0jP3mIatHbObomVjaby6vba74imOQEfY3JIQHkUQL3w2E 4GW/G9ZczACcjaJuEO2CpWAhm2qUNiZdJEf12xcEZKNgZTzVm1RIDzcTSfpZRuDP8yc= X-Gm-Gg: AR+sD10/kJMhg85+Nya3WzoJ3mFa0r445ZVIZ0TAfhb/1o/UgimJpCxX8zsK71wWybf 8h1qIYfJhtplIyUqZl03JB0hoLKqn5hx87rVDzjy2lerrYsjIKd94dWmDHuDZ/585WI7mA0L4bv 8n+IIxk5sAerJr4NSdmWmGv70FFI/8r3NcPMzxUtltKGwBotcOwAX7F14DzieHc7G+z3pdPTVLl GW5Tvb8zG1VNEkDVlhAKqaV4SuRS2GEy4ovIEgL2tA7WtIRlBPKkk7rjgY2TZya3beVVFsoOzIa EV3qBvJNxF19DeNrVd3s4zH24D6UOjh0/5uhALUYdKbo/xoGluyShQqpakQMIYPyTs1+Z6z7TGb Z8xbUiZeRN028u6NrKrZGgkcH1gQvaBxuE7R2Jsoj7vfFZXjjb8rIb72NCX/D1ryZezPq68r2ZH 7B6EYBTVpnZfCnM/XNasZC1emCjobARvZCOYXr+vUhbpSSzUod3N2tVs72x1leOA/tvW4uXL9Bt V7SkiFm X-Received: by 2002:a17:907:97d5:b0:c20:21be:ea75 with SMTP id a640c23a62f3a-c246a33ea8bmr1572189166b.8.1787428376741; Sat, 22 Aug 2026 12:52:56 -0700 (PDT) Received: from ownbook.home.lex.la ([84.17.55.225]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2495ee5295sm475032666b.0.2026.08.22.12.52.55 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sat, 22 Aug 2026 12:52:56 -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 1/2] net: dsa: mt7530: populate lpi_interfaces to fix EEE support Date: Sat, 22 Aug 2026 22:52:51 +0300 Message-ID: <20260822195252.2934-2-f@lex.la> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260822195252.2934-1-f@lex.la> References: <20260822195252.2934-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 config->lpi_capabilities and config->lpi_timer_default, but never populates config->lpi_interfaces. phylink only treats a MAC as supporting phylink managed EEE when the tx_lpi methods are implemented and both the LPI capabilities and the LPI interfaces are non-empty, so EEE is unavailable on every port: # ethtool --show-eee lan1 Cannot get EEE settings: Not supported even though the driver implements mac_enable_tx_lpi() and mac_disable_tx_lpi() and reads the LPI threshold back out of PMEEECR. Since the tx_lpi methods are implemented, phylink takes the other branch and calls phy_disable_eee(), which fills eee_disabled_modes, so userspace cannot enable EEE either. Only the first half of what commit 06dfcd4098cf ("net: dsa: mt7530: fix enabling EEE on MT7531 switch on all boards") arranged therefore survives. It left EEE off out of the box on purpose, by having mt7531_setup() clear the switch PHYs' EEE advertisement, and ended "With this change, EEE can now be enabled using ethtool". It cannot be, any more. Copy the supported interfaces into lpi_interfaces. This requires moving the mac_port_get_caps() call ahead of the EEE block, since that is what populates supported_interfaces - copying it beforehand would copy an empty bitmap. LPI stays off by default. The driver does not set eee_enabled_default, so phylink leaves tx_lpi_enabled false, and phy_check_link_status() computes enable_tx_lpi as tx_lpi_enabled && eee_active - nothing asserts LPI until userspace enables it with ethtool --set-eee. The EEE advertisement is the part that does change: phylink no longer takes the phy_disable_eee() branch, so a PHY that advertises EEE out of reset advertises it again and the link may negotiate EEE. MT7531's five internal PHYs are the exception, as mt7531_setup() zeroes MDIO_AN_EEE_ADV before the switch MDIO bus is registered, so phy_probe() reads an empty advertisement and records eee_cfg.eee_enabled as false. Nothing does that for an external PHY on port 5 or 6, or on the other mt753x variants, EN7528 aside - see below. This also makes lpi_capabilities take effect for the first time, so correct its value in the same change. PMCR only has force bits for 100 Mbps (PMCR_FORCE_EEE100) and 1 Gbps (PMCR_FORCE_EEE1G), and PMSR only reports EEE state for those two speeds, so the MAC cannot signal LPI at 2.5 Gbps: drop MAC_2500FD. Absence from the header is weak evidence on its own, so for what it is worth, the Airoha AN8855 DSA driver - posted but not merged [1] - describes a PMCR of the same shape that does carry AN8855_PMCR_FORCE_EEE2P5G and AN8855_PMCR_FORCE_EEE5G next to the 1 Gbps and 100 Mbps bits. Correcting the value here rather than in a separate patch changes nothing observable: while lpi_interfaces was empty, lpi_capabilities never reached phy->advertising_eee, so no state ever claimed 2.5 Gbps LPI. 2500BASE-X has to come out of lpi_interfaces as well, because lpi_capabilities cannot express it: it masks the PHY's EEE advertisement, a media side property, and never gates LPI activation on the MAC side speed. phylink raises the MAC speed to the interface maximum when the PHY rate matches (RATE_MATCH_PAUSE in phylink_link_up()), so a 1 Gbps media link behind a rate matching 2.5G PHY would otherwise arm LPI while the MAC runs at 2.5 Gbps. What that costs is limited to setups that keep the MAC on 2500BASE-X, where there are no LPI bits to use anyway; a PHY that switches the interface down to SGMII or 1000BASE-X keeps LPI, as those stay in the mask. For the same reason, skip ports that support neither 100 Mbps nor 1 Gbps: on MT7988, EN7581 and AN7583, port 6 is 10 Gbps only, and it shares PHY_INTERFACE_MODE_INTERNAL with the 1 Gbps user ports, so the interface mask alone cannot tell them apart. EEE remains unavailable on EN7528, whose GPHYs do not negotiate it reliably. Both LPI bitmaps stay empty there, so phylink keeps taking the phy_disable_eee() branch and its advertisement stays off. [1] https://lore.kernel.org/r/20250315154407.26304-14-ansuelsmth@gmail.com 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, which is the raw LPI_THRESH field; 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; deliberately not bundled into a fix. 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..17265eb79008 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, as PMCR has no force bit that would apply to them. */ - 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 only has force bits for 100 Mbps and 1 Gbps. That also + * rules out 2500BASE-X, which lpi_capabilities cannot express: + * it masks the PHY's EEE advertisement, a media side property, + * and never gates LPI activation on the MAC side speed. 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. + */ + 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 10:44:09 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 71A35367F41 for ; Sat, 22 Aug 2026 19:53:00 +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=1787428382; cv=none; b=h9Znbi94JcL6sbXlqWiDOH97/MLUCuCjb1CeJ1j2eBOLkj82CkT3Ca7T1d4NBSNK90d5i+TxTo1D+n3ptLV2buqPoMMAw9txxcCaKMdHOT3uhnA7XQ5p/MQzW1faP4guVSbuoO8jo3MRk9zCQo6mbBYUvbpTGUdueuepM5ig7E4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787428382; c=relaxed/simple; bh=rYDFwLmw4rqtLoCuHgoPh3rMzXjmfiowCEUJa3nZGcQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ju/X3BRmcMxE99bFRa1a454Yp0CJ+s/8FAeqaevswui92FRiH59vgqqxtMmAmIA2mupOLr4qYX0b4NJFZUjMZofcA+fLHOiqCAxR3c7FyZPZQx5Vrgo6QL07yWeI4Q7cinRT+uDcU079E76oBMcBDRgahm7v0TVf0L1gkTue+58= 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=Qu580He+; 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="Qu580He+" Received: by mail-ej1-f54.google.com with SMTP id a640c23a62f3a-c15f020a223so317664066b.1 for ; Sat, 22 Aug 2026 12:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lex.la; s=google; t=1787428379; x=1788033179; 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=0uy0OKeVpCAmhbj0eyrSB4RHofJlj5Ul/6v78/RLpNA=; b=Qu580He+uEEIL3Dh+cu3R6tAxCK57MEYM7jRPG4147jv28KQUuH61s6w47b/3S5i8A 3TYQD5lLsaoqV5ctbfuZfT+t6LM5YBOXLrlk9wOQTQYVlIkGJKbCorPJnr5X0Wa0fOY2 zc8yH/UHBhv+iz3vVsNlNo1PP2HECYyKiKdGozNKC4GFZ2/LWoaED/8/YA+Lm66Km3FT JbF6E6IC4c5A6fdafUnQyCTjnUpRSMQCZbL/oLnUKfurcCr8g+D2/jDCypkyoD4GJup1 ojjbCDTn4YV3zeWPDtiUUjzh3iNdHj+iIkTdESTKQDRcdj33oPtQTRCQILNBgQd4xRM7 KHMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787428379; x=1788033179; 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=0uy0OKeVpCAmhbj0eyrSB4RHofJlj5Ul/6v78/RLpNA=; b=a0bqoIwGjg2W5nzPJhdbDAoB6qworpyEnPL91dF+pMp8/c0LUiyhg/3q6D2K+v43mq WuVvyIo9FGeDRV1lc+phNF1ABWoMQEZpDG4C2rQXJXXtrj1v7L2qQTdqWx1wp/FLlLZc hfFPf7QAPq/0Q9JEkCxpu9hQp4QvUVQe/hcyHWzqq0CZCDIBbLXUX4WbG+ujKGWAQQz7 aVkHU3s4rr9AC6IO9FSCWp5Iz9ugXvw4BX5T9mVfoETeFU98MLi46H0OyeTA0FyVtSvM 91+G9SfcWvXrhp+kQVSVkuM6sERzxGC4pVg9FEgVB2Iq8nIErHxNOMERuYsOYv9soBk4 012w== X-Forwarded-Encrypted: i=1; AHgh+RoDxXcM6F/BjONr7p3WlHw778zKj/ifLOSLuZXyWquHKgfACeFgM8la16MpilWb+/38nyiXq67mfk0o2n4=@vger.kernel.org X-Gm-Message-State: AFuF++nTcGhZcxq1aEpSiQweH5IlE325OZ7eEgTsMJxBsVtnnjXLZUhV F8fKgDtYzb1j12pnbqPiYaWCODdF6vl+SfR14S0Qz/Nlrnau4VN96fK1JXJsLeuPspY= X-Gm-Gg: AR+sD11JY+FcQMhC/qefNOTRbFTdThkhTApDoXWwhsMIFcihE56pX0+RNSBMgEdcsRN rMlzz4pVBUvtMphQQTd9UXp1KxJUS/wVgWMerXi2G9/kHlFr1vy5OvhYnPzz8PvGQAy8kEB1vNy GJeX9dqGTq+uUXMIyVcVrI5ewK7jXph49HeOK23gnWBWG7G/D6Lrh2A7tkNKekG/fjfPP/vlEES NQVFCsaPGZhNMqJI8v/F3qduCoVB0k2MtBGxJlLtszekgJOSPQWMEJ97tWBu3NHb/LmbdCd8y9u d+rCVnIQ5eGfUE6mrBIYxxN+ltOkeVhAuneekfmEkn69gnJAG2GBlYVFgCmVLNnJQ/zA4DbN+fw dvOAO3YD1Kb3voiX2r79BtSSSSA4ecFE7UBTs0x6W/EdogZ+4iFWiAUPi2AWkMiOdTwkO5gh9jA X0BSeL1qCH74M8tUiDnE1y5BbO98T14wT9l+eo1w10oUD0/HYij1xx0ELhoYLIWslGaAZnTZanc Mzu1xrH X-Received: by 2002:a17:907:ea8b:b0:c21:2c32:e2da with SMTP id a640c23a62f3a-c246a5f4515mr1912226866b.8.1787428378632; Sat, 22 Aug 2026 12:52:58 -0700 (PDT) Received: from ownbook.home.lex.la ([84.17.55.225]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2495ee5295sm475032666b.0.2026.08.22.12.52.56 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sat, 22 Aug 2026 12:52:58 -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 2/2] net: ethernet: mtk_eth_soc: populate lpi_interfaces to fix EEE support Date: Sat, 22 Aug 2026 22:52:52 +0300 Message-ID: <20260822195252.2934-3-f@lex.la> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260822195252.2934-1-f@lex.la> References: <20260822195252.2934-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 phylink_config.lpi_capabilities and phylink_config.lpi_timer_default, but never populates phylink_config.lpi_interfaces. phylink only treats a MAC as supporting phylink managed EEE when the tx_lpi methods are implemented and both the LPI capabilities and the LPI interfaces are non-empty, so EEE is unavailable on every MAC that uses mtk_phylink_ops: # ethtool --show-eee wan Cannot get EEE settings: Not supported even though those ops implement mac_enable_tx_lpi() and mac_disable_tx_lpi(). Since the methods are implemented, phylink takes the other branch and calls phy_disable_eee(), which fills eee_disabled_modes, so userspace cannot enable EEE either. MT7628 is unaffected, as rt5350_phylink_ops has no tx_lpi methods at all. Copy the supported interfaces into lpi_interfaces once they are complete, that is after the SoC specific fixups have added and removed modes. In particular the netsys v3 switch path clears the bitmap before setting PHY_INTERFACE_MODE_INTERNAL, so copying it any earlier would leave stale modes behind. The MAC does not start using LPI on its own: the driver does not set eee_enabled_default, so phylink leaves tx_lpi_enabled false, and phy_check_link_status() computes enable_tx_lpi as tx_lpi_enabled && eee_active. One thing does change, and it is worth being explicit about: phylink no longer takes the phy_disable_eee() branch, so a PHY that advertises EEE out of reset advertises it again instead of being forced quiet, and the link may negotiate EEE where it previously could not. Nothing on this side asserts LPI until userspace enables it with ethtool --set-eee. This also makes lpi_capabilities take effect for the first time, so correct its value in the same change. MAC_MCR only has EEE force bits for 100 Mbps (MAC_MCR_EEE100M) and 1 Gbps (MAC_MCR_EEE1G), and MAC_EEECR only carries wakeup times for those two speeds (MAC_EEE_WAKEUP_TIME_100, MAC_EEE_WAKEUP_TIME_1000), so the MAC cannot signal LPI at 2.5 Gbps: drop MAC_2500FD. Correcting the value here rather than in a separate patch changes nothing observable: while lpi_interfaces was empty, lpi_capabilities never reached phy->advertising_eee, so no state ever claimed 2.5 Gbps LPI. Two sets of interfaces have to come out of lpi_interfaces as well. lpi_capabilities cannot express either: it masks the PHY's EEE advertisement, a media side property, and never gates LPI activation on the MAC side speed, while phylink raises the MAC speed to the interface maximum when the PHY rate matches (RATE_MATCH_PAUSE in phylink_link_up()), so 2500BASE-X would arm LPI on a 2.5 Gbps MAC even for a 1 Gbps media link. Separately, mtk_mac_enable_tx_lpi() refuses the xGMII modes outright, which on netsys v3 includes PHY_INTERFACE_MODE_INTERNAL, the mode MT7988's built-in 2.5G PHY runs in; offering those to phylink would log an error on link up once EEE is enabled. What that costs is limited to setups that keep the MAC on 2500BASE-X or on an xGMII mode, neither of which the MAC has LPI bits for; a PHY that switches the interface down to SGMII or 1000BASE-X keeps LPI, as those stay in the mask. On the netsys v3 switch MAC, that empties lpi_interfaces outright, since PHY_INTERFACE_MODE_INTERNAL is the only interface it supports. Nothing changes there: it is a fixed link port with no PHY, so phylink had no EEE to manage on it before this patch either. Fixes: 952d7325362f ("net: ethernet: mediatek: add EEE support") Signed-off-by: Aleksei Sviridkin --- 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. 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..5412c89685f2 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 only has EEE force bits for 100 Mbps and 1 Gbps, and + * MAC_EEECR only has wakeup times for those two speeds, so the MAC + * cannot signal LPI at 2.5 Gbps. + */ + 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