From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) (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 B0A1B37473A for ; Mon, 24 Aug 2026 02:41:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787539287; cv=none; b=Yuq6QTDWvY6qYnkY2MxmHBU84pJR//GzKXnFGnjoIgcBAuAy7BmxFavpJjPtftSAGWP+MZvpKJ/QWKJTWU4xOY3yyXPts8FWqBnKABUfh0k2YwquVDoYs6wuVLFVhaB66Yn1EN/YXNvDlqBXd21sBm48w07euKQx1ThQosdJeJo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787539287; c=relaxed/simple; bh=eVMlWxVQr7oL7OUokGCpCcdwoLSXrn/87RDA9InGgTc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=kqdSJnGeGiHSpBvcRLaq6QdUgggufK+9CTOsZ+n978h/7q+GYyeUyBEacSM0bjDb9CydF9W9NkT6ibA0ecB4eK/yE1bY8m0OswjOLHQZqDqPXAm8nzjxwIzb6oFuUua2nN54yzkmgmEVIm3lDfMzWts9EtxcrSY9mKrerL1uVa4= 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=e/EGfYVk; arc=none smtp.client-ip=209.85.218.50 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="e/EGfYVk" Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-c15d47266baso330824066b.3 for ; Sun, 23 Aug 2026 19:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lex.la; s=google; t=1787539282; x=1788144082; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=eQDlZUqXKTPfwqBY8N8tCdcmyCJmkDuzU6UtMMpoHKM=; b=e/EGfYVk6LSSA3yqgVyiuaeUdoqzvHeMezDHGaodWz+FsZnkD+/aUxOmf/ExLXCw67 mJ3G6cvim9JdKLnQHYHM+VTxLgA0yuNozrcvl9Izoo74IEyBuumlN7PEi+vEjU8umBJN q1pdo3zg9P/QB7x8UTpO4geBlCT9XRJFJTkZylJ9SwPljAGSt4D57wnYkSnDIh45Rj0y P7AuvvZC/kswSoowwI3jVLCE+ry9bD0P8v9b5Wfsg3VtOthCYr3z4mi9+c5HfyEpKgVQ CxeJPQRhBkTk/qQFziLsHa0WA99ISWOkRhci7rdcY9tBZl70ALol0UdeEmz9fHYqIcN3 d6YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787539282; x=1788144082; h=content-transfer-encoding:mime-version: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=eQDlZUqXKTPfwqBY8N8tCdcmyCJmkDuzU6UtMMpoHKM=; b=pYlf3MOWOM/641MZDfLZJnS8y0fYHXpUVxsN1dosMxpggYcAyk8Zqr2B5pGhtqp/1b xknkoCJwf+3ZG3ZsAacGwIsaRzRqVsZdSTneK5TGPrNuX0y6LyjjNbYeqTbUCkzVAYsX +A1tKf+l5RTnwvqaIvk4eD7bjZlpYvHoT3XBsp9HwKGu0MUk8ERKzLBlgFOprr55cvZf VRimuIPBu5QdoKynoU9SyHl2C81cybv8ckOcz8yb5eGJ779HChcTgZHzkLLgixWt2DDc rPZVanAU3izkLxjgvN7eoLH+R4WnitdHmrnzMtw2mh6zXxjDepIG6JVP8twXB5CvqbW6 eH9A== X-Forwarded-Encrypted: i=1; AHgh+RqDbIKD0bpzzorD2zXll9hu9Bw7mKtrbAHU22Dbn7iCteRJ0SiKeEv7CqxUAOLEcCawhKU2Q29+DENEuC8=@vger.kernel.org X-Gm-Message-State: AFuF++k4/J1uGECL12wkK7NJWOmqhDzE1xfEf87yYzIBB8NOB815cji4 ILLAp+cC/36H+BUaK2cmhM1ZdVt/oeg4M91j5QInYrL2nhNenTf/qe7CqFqgmMn60SY= X-Gm-Gg: AR+sD11anE7cSqkMQ8NlA/uhKPdoNJKLHQGUV3i6cE3RyJnq6iw/faDd+L+9iaHsEoR Dl04shc5DKHLI0O6apor2Fl4IV/3bDMEaO2HLp3IV8i4iOflzXlyoxUkQ5BF4fTAWDS3hfJ1CUW PcNJ3+4IRivPeQlfD/ZInmJPahmk6CmDNGD4cxgNSrMe88wWrJv4QwhB8O+XXS3qY+EOf2/SV6c D3TXX2oScpz9UhHblj2pex+joLZRCr+/xYaUDy6k65BmeFbdUL6UhVCABcPWJjtPvi/5P7aZ0xe fPDyJsQh8cHZynsK9UAibpqrq+mzAy9PGDBfkSBcHqmkTyFboxPvNu+j5lta65MMlXFndcM1seQ vArxdF7lx4RXP75KF35Emw1yNPkxjYcXnmJYQmVAL31uJni7YC7cQOCUbaaYWpkdp5shQU29afU zbVQqLBj3ZFOyoH9yJd6N7nhSzhF0Lzz5a9ZbXbsR7DcHQgZuTW+XLWUjy X-Received: by 2002:a17:907:97d5:b0:c20:21be:ea75 with SMTP id a640c23a62f3a-c246a33ea8bmr2393322466b.8.1787539282331; Sun, 23 Aug 2026 19:41:22 -0700 (PDT) Received: from ownbook ([195.181.160.194]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c249686e37bsm949008466b.55.2026.08.23.19.41.18 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sun, 23 Aug 2026 19:41:21 -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 0/2] net: restore EEE on MediaTek switches and SoC MACs Date: Mon, 24 Aug 2026 05:41:15 +0300 Message-ID: <20260824024117.46154-1-f@lex.la> X-Mailer: git-send-email 2.55.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Both drivers fill in phylink_config.lpi_capabilities and lpi_timer_default but never lpi_interfaces. phylink treats a MAC as supporting managed EEE only when the tx_lpi methods are implemented and BOTH bitmaps are non-empty, which phylink_create() decides once and for all, so EEE has been off on every mt753x port and on every mtk_eth_soc MAC that uses mtk_phylink_ops since the two conversions named in the Fixes: tags. Because 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. On an MT7981B board with an MT7531 switch, before these patches: == lan1 Cannot get EEE settings: Not supported == lan2 Cannot get EEE settings: Not supported == lan3 Cannot get EEE settings: Not supported == lan4 Cannot get EEE settings: Not supported == wan Cannot get EEE settings: Not supported lan1-3 are the MT7531 internal PHYs, lan4 is an EN8811H on switch port 5 whose MAC side runs 2500BASE-X rate matched to a 1 Gbps media link, and wan is the mtk_eth_soc MAC with its directly attached 1 Gbps PHY - so both drivers are covered. Each patch fills lpi_interfaces from supported_interfaces and leaves 2.5 Gbps out of both bitmaps for now. LPI above 1 Gbps is unvalidated rather than unsupported: both MACs fold 2.5 Gbps onto their 1 Gbps speed encoding, so the 1 Gbps EEE force bit is what would govern it. MediaTek's SDK driver sets the force bits for 100 Mbps and 1 Gbps only, EEE signalling on 2500BASE-X is outside 802.3, and the 1 us unit of the wakeup timers is undocumented at 2.5 times the port clock. Neither driver sets eee_enabled_default, so LPI stays off until userspace asks for it with ethtool --set-eee. The EEE advertisement is a different matter: phylink stops force-clearing it, so a PHY that advertises EEE out of reset advertises it again and the link may negotiate EEE, without this MAC asserting LPI. MT7531's internal PHYs and EN7528 are the exceptions, for the reasons in patch 1. Devicetree eee-broken-* marks act at the PHY level and keep working, so a board that already distrusts its PHYs stays protected: OpenWrt marks all modes broken on MT7621's internal PHYs. The two patches are independent and touch different subsystems; they are sent together because they are the same bug. Targeted at net as a regression fix with an active userspace lockout; can be retargeted at net-next if maintainers prefer. Based on net-next at 91ec20351349. Both driver files are byte identical in net/main and the series applies there unchanged. After the series, all five ports report: EEE status: disabled Tx LPI: disabled Supported EEE link modes: 100baseT/Full 1000baseT/Full Advertised EEE link modes: Not reported No 2.5G mode is offered, which is the narrowed lpi_capabilities, and nothing is advertised until userspace asks. On this board no PHY came out of reset advertising EEE, so the case where the advertisement returns once phylink stops clearing it is not exercised here. Enabling it on lan1, whose partner advertises EEE at both speeds: # ethtool --set-eee lan1 eee on EEE status: enabled - active Advertised EEE link modes: 100baseT/Full 1000baseT/Full Link partner advertised EEE link modes: 100baseT/Full 1000baseT/Full # ethtool --set-eee lan1 eee on tx-lpi on EEE status: enabled - active Tx LPI: 30 (us) With LPI armed, 30 parallel ICMPv6 streams of 1400-byte payload, 300 packets each one second apart - so every gap crosses the LPI threshold and the link enters and leaves LPI thousands of times over 300 s - lost nothing: 300/300 on every stream, tx and rx error counters unchanged, carrier_changes unchanged, and no mac_enable_tx_lpi errors in dmesg. On wan the link partner advertises no EEE, so enabling it settles at "enabled - inactive", which is the correct outcome, and the link survived the autonegotiation restart. Its Tx LPI reads 1000 (us) against lan1's 30; see the note below the scissors of patch 1. lan4 keeps EEE disabled and never arms LPI, which is what dropping 2500BASE-X from lpi_interfaces is for. Forwarding through it was lossless with no carrier change. --- v2: commit messages rewritten to carry the Why only, mechanism notes moved below the scissors (Andrew Lunn); comments and commit messages reworded so the 2.5 Gbps exclusion reads as unvalidated rather than impossible (Daniel Golle); no functional changes. v1: https://lore.kernel.org/netdev/20260822195252.2934-1-f@lex.la/ Aleksei Sviridkin (2): net: dsa: mt7530: populate lpi_interfaces to fix EEE support net: ethernet: mtk_eth_soc: populate lpi_interfaces to fix EEE support drivers/net/dsa/mt7530.c | 24 ++++++++++++++++----- drivers/net/ethernet/mediatek/mtk_eth_soc.c | 22 ++++++++++++++++--- 2 files changed, 38 insertions(+), 8 deletions(-) -- 2.55.0