[RFC PATCH net] r8169: avoid 2.5G EEE by default on RTL8125D rev.a

[iugfdin]

A reported RTL8125D rev.a (XID 688, PCI rev 0c) loses packets,
including gateway ICMP, when 2.5G EEE is active, without
reported NIC error counters increasing. It uses rtl8125d-1_0.0.7
firmware and a 2.5GbE switch. Disabling EEE on the unmodified
driver removes the observed loss while retaining 2.5Gbps.

Default this revision to advertising EEE only at the lower supported
speeds. Preserve 2.5G EEE capability and allow userspace to opt in
explicitly on compatible links; do not permanently mask it using
phy_disable_eee_mode(). Ordinary 2.5G link advertisement is unchanged.

Pass the matched chip entry into MDIO registration because D1, D2
and other chips share RTL_GIGA_MAC_VER_64. Change only the entry
matching XID 688, leaving the other revisions' policy unchanged.

Fixes: f75d1fbe7809 ("r8169: add support for RTL8125D")
Assisted-by: LLM
Signed-off-by: iugfdin <iugfdin@xxxxxxxxx>
---
RFC because this is a conservative default-policy mitigation for one
reported card/switch combination, not a demonstrated LPI signaling fix.
Review of the scope and a feature-preserving root-cause fix is welcome.
The observations do not distinguish a NIC-side defect from a peer-side
defect or an interoperability problem between the two PHYs.

Hardware evidence:
  - Original r8169: EEE enabled-active at 2.5G, packet loss.
  - Original r8169, EEE off: 2.5G retained, no loss reported.
  - Earlier hard-mask candidate: EEE requested on but enabled-inactive,
    lower EEE advertisement, NetworkManager reports 2.5G, and the
    reporter says "no packet loss it seems".
  - This revision uses the same initial advertisement but preserves
    explicit opt-in. Its exact binary has not yet been tested on the
    affected NIC. No measured packet counts or duration are available.

The verified Realtek Windows 11 package 11.031.50 selects an EEE
ceiling of 1000 for generic RTL8125D and offers 2500 as a user setting.
That is an INF default, not an observation of this machine's Windows
EEE state. Realtek Linux r8125 9.018.00 allows 2.5G EEE; the reporter
has not checked whether EEE was active in the working vendor run.

Comparing the source did not identify a different standard EEE timer
or advertisement mapping. The vendor additionally clears MAC OCP E052
bit 0 and PHY OCP A442 bits 12/13 and A430 bit 15, with a conditional
PHY MCU patch handshake. Upstream does not explicitly perform those
clears, but the affected device's live values and firmware effects
are unknown. Could Realtek advise whether that initialization is
required on D1? Blindly copying undocumented writes would not establish
a repair.

Policy verification extracts actual chip dispatch, MDIO registration,
phylib helpers and C45 get/set/negotiation routines, with modeled MDIO
hardware. The hard restriction fails eight capability/opt-in checks;
this revision passes all 164. Ordinary 2.5G and other chip policies,
EEE off/on retention and explicit opt-in are covered. The two earlier
TX regression matrices also pass 85 and 102 checks. These tests do
not simulate physical LPI timing.

No Tested-by is asserted for this exact revision.

diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index ae8ea0d8..ded31ead 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -5425,7 +5425,8 @@ static int r8169_mdio_write_reg_c45(struct mii_bus *mii_bus, int addr,
 	return 0;
 }
 
-static int r8169_mdio_register(struct rtl8169_private *tp)
+static int r8169_mdio_register(struct rtl8169_private *tp,
+			       const struct rtl_chip_info *chip)
 {
 	struct pci_dev *pdev = tp->pci_dev;
 	struct mii_bus *new_bus;
@@ -5486,6 +5487,13 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
 		phy_disable_eee_mode(tp->phydev,
 				     ETHTOOL_LINK_MODE_2500baseT_Full_BIT);
 
+	/* RTL8125D rev.a can lose packets with 2.5G EEE on some link
+	 * partners. Leave it available for explicit opt-in.
+	 */
+	if (tp->mac_version == RTL_GIGA_MAC_VER_64 && chip->val == 0x688)
+		linkmode_clear_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
+				   tp->phydev->advertising_eee);
+
 	/* Keep EEE off but the version stays EEE-capable so that link-up
 	 * still clears the MAC TX-LPI bits.
 	 */
@@ -5796,7 +5804,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 
 	pci_set_drvdata(pdev, tp);
 
-	rc = r8169_mdio_register(tp);
+	rc = r8169_mdio_register(tp, chip);
 	if (rc)
 		return rc;