[PATCH 6.6.y] net: usb: lan78xx: program MAC_CR for LAN7801 fixed-PHY link

[PATCH 6.6.y] net: usb: lan78xx: program MAC_CR for LAN7801 fixed-PHY link

[Nguyen Minh Tien]

While bringing up a LAN7801 wired over RGMII to an MDIO-less switch, I
hit a link that the fixed PHY reported as "up" but that could not pass a
single packet: every frame came out corrupted at the switch and no ARP
reply ever made it back.

It turned out the MAC_CR speed/duplex bits are never set on this path.
lan7801_phy_init() registers a fixed PHY at SPEED_1000/DUPLEX_FULL, but
nothing programs the MAC to match: there is no PHY state machine for a
fixed link, and lan78xx_reset() only sets the auto speed/duplex bits for
the 7800.  So the 7801 comes up at 10M/half, clocks RGMII TXC at 2.5 MHz
instead of 125 MHz, and mangles everything it transmits.

Fix it by programming MAC_CR to 1G/full in the fixed-PHY branch, to match
fphy_status.  Only that branch is touched, so boards with a real external
PHY (and the 7800/7850) are unaffected.

Mainline fixes this differently via the phylink conversion in v6.16,
commit e110bc825897 ("net: usb: lan78xx: Convert to PHYLINK for improved
PHY and MAC management"), which is far too large to backport, so this is
a small fix for stable only.

Please apply to 6.1.y, 6.6.y and 6.12.y, the pre-phylink branches that
still carry this bug.  Built and tested on 6.6.y; the touched code is
identical on 6.1.y and 6.12.y.

Fixes: 89b36fb5e532 ("lan78xx: Lan7801 Support for Fixed PHY")
Cc: stable@vger.kernel.org
Signed-off-by: Nguyen Minh Tien <zizuzacker@gmail.com>
---
 drivers/net/usb/lan78xx.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index f5bcf150fd9e..6b94f6026472 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -2325,6 +2325,22 @@ static struct phy_device *lan7801_phy_init(struct lan78xx_net *dev)
 		buf |= HW_CFG_CLK125_EN_;
 		buf |= HW_CFG_REFCLK25_EN_;
 		ret = lan78xx_write_reg(dev, HW_CFG, buf);
+
+		/* Nothing programs MAC_CR for the fixed link: reset() only
+		 * sets speed/duplex for the 7800, so the 7801 is left at
+		 * 10M/half and mangles every frame it sends.  Force it to
+		 * match the 1G/full fphy_status above.
+		 */
+		ret = lan78xx_read_reg(dev, MAC_CR, &buf);
+		if (ret < 0)
+			return NULL;
+		buf &= ~(MAC_CR_AUTO_DUPLEX_ | MAC_CR_AUTO_SPEED_ |
+			 MAC_CR_ADP_ | MAC_CR_GMII_EN_ |
+			 MAC_CR_SPEED_MASK_);
+		buf |= MAC_CR_SPEED_1000_ | MAC_CR_FULL_DUPLEX_;
+		ret = lan78xx_write_reg(dev, MAC_CR, buf);
+		if (ret < 0)
+			return NULL;
 	} else {
 		if (!phydev->drv) {
 			netdev_err(dev->net, "no PHY driver found\n");
-- 
2.34.1

Re: [PATCH 6.6.y] net: usb: lan78xx: program MAC_CR for LAN7801 fixed-PHY link

[Greg KH]

On Fri, Jun 05, 2026 at 07:15:35PM +0700, Nguyen Minh Tien wrote:
> While bringing up a LAN7801 wired over RGMII to an MDIO-less switch, I
> hit a link that the fixed PHY reported as "up" but that could not pass a
> single packet: every frame came out corrupted at the switch and no ARP
> reply ever made it back.
> 
> It turned out the MAC_CR speed/duplex bits are never set on this path.
> lan7801_phy_init() registers a fixed PHY at SPEED_1000/DUPLEX_FULL, but
> nothing programs the MAC to match: there is no PHY state machine for a
> fixed link, and lan78xx_reset() only sets the auto speed/duplex bits for
> the 7800.  So the 7801 comes up at 10M/half, clocks RGMII TXC at 2.5 MHz
> instead of 125 MHz, and mangles everything it transmits.
> 
> Fix it by programming MAC_CR to 1G/full in the fixed-PHY branch, to match
> fphy_status.  Only that branch is touched, so boards with a real external
> PHY (and the 7800/7850) are unaffected.
> 
> Mainline fixes this differently via the phylink conversion in v6.16,
> commit e110bc825897 ("net: usb: lan78xx: Convert to PHYLINK for improved
> PHY and MAC management"), which is far too large to backport, so this is
> a small fix for stable only.

Why is that too large?  If we take this, we then diverge and any future
fixes will not apply here :(

Please backport exactly what is in the mainline tree, otherwise odds
are, this one-off fix will be found incorrect (we always get it
wrong...)

thanks,

greg k-h