[PATCH net v2] net: phy: realtek: restore RTL8211F RGMII delays on resume

[PATCH net v2] net: phy: realtek: restore RTL8211F RGMII delays on resume

[Karl Mehltretter]

RTL8211F and RTL8211F-VD both use rtl8211f_config_rgmii_delay() during
initialization and share rtl821x_resume(). The RTL8211F-VD loses its
RGMII TX and RX delay enable bits across a software power-down, but the
shared resume path only clears BMCR_PDOWN and waits for the receive clock
to stabilize.

On a BeagleV Ahead configured for rgmii-id, carrier and the negotiated
speed return after an interface close/open, but the receive path does not
work. At 100 Mbit/s no frames were received. At 1000 Mbit/s all 11
observed frames had CRC errors.

Reapply the RGMII delay configuration after the existing resume delay.

Tested on a BeagleV Ahead with an RTL8211F-VD at 100 and 1000 Mbit/s,
including close/open without a link partner.

Fixes: bb726b753f75 ("net: phy: realtek: add support for RTL8211F(D)(I)-VD-CG")
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
v2:
- Move the shared RTL8211F/RTL8211F-VD resume-path explanation earlier.
- Add Andrew's Reviewed-by.

v1: https://lore.kernel.org/netdev/20261014033659.95196-1-kmehltretter@gmail.com/

Hardware test results on BeagleV Ahead (RTL8211F-VD, rgmii-id):

                               baseline          patched
 100 Mbit/s close/open         RX silent         pass
 1000 Mbit/s close/open        11/11 CRC errors  pass
 no-link close/open, reconnect 15/15 CRC errors  pass

The patched kernel also passed bidirectional 1 MiB SHA-256 transfers at
100 and 1000 Mbit/s and eight consecutive 1000 Mbit/s close/open cycles,
all without RX CRC errors. An s2idle suspend/resume test passed on both
kernels and did not reproduce the bug.

Testing on an RTL8211F (non-VD) would be welcome.

Built with ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- LLVM=1.

 drivers/net/phy/realtek/realtek_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
index 177b62a7b2d16..c867e5213216b 100644
--- a/drivers/net/phy/realtek/realtek_main.c
+++ b/drivers/net/phy/realtek/realtek_main.c
@@ -1375,7 +1375,7 @@ static int rtl821x_resume(struct phy_device *phydev)
 
 	msleep(20);
 
-	return 0;
+	return rtl8211f_config_rgmii_delay(phydev);
 }
 
 static int rtl8211f_resume(struct phy_device *phydev)
-- 
2.39.5 (Apple Git-154)

Re: [PATCH net v2] net: phy: realtek: restore RTL8211F RGMII delays on resume

[Karl Mehltretter]

On Thu, Oct 15, 2026 at 06:50:01AM +0100, Karl Mehltretter wrote:
> Reapply the RGMII delay configuration after the existing resume delay.
> 
> Tested on a BeagleV Ahead with an RTL8211F-VD at 100 and 1000 Mbit/s,
> including close/open without a link partner.
> 
> Fixes: bb726b753f75 ("net: phy: realtek: add support for RTL8211F(D)(I)-VD-CG")
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> Assisted-by: LLM
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
> ---
> v2:
> - Move the shared RTL8211F/RTL8211F-VD resume-path explanation earlier.
> - Add Andrew's Reviewed-by.
> 
> v1: https://lore.kernel.org/netdev/20261014033659.95196-1-kmehltretter@gmail.com/
> 

Now Sashiko found a possible clock reference leak in the resume error
path:

https://sashiko.dev/#/patchset/20261015045001.83986-1-kmehltretter@gmail.com

I'll take a look.

Karl