Re: [PATCH v2 06/10] net: pcs: xpcs: add ANRESTART support for SGMII link recovery
Coia Prant <[email protected]> Sun, 2 Aug 2026 11:11:40 +0800
| Newsgroups | org.kernel.vger.linux-renesas-soc,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-phy,org.infradead.lists.linux-rockchip,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel,org.kernel.vger.netdev |
|---|---|
| Message-ID | <CALj3r0i1TCTgvm8FrJAJqmZgoJp61NCxc_xmVYaDFd-gh4H=7w@mail.gmail.com> |
Hi Andrew, Thanks for the careful review. > This probably needs more wide spread testing. I would be afraid that > if you kick off an AN cycle, you loose the link until it completes? > You would of noticed that on your hardware, but other hardware > obviously behaves differently... The trigger condition is: link is down AND an_complete is set. This means auto-negotiation has already completed (or completed with failure), but the link is still down. In this state, the hardware will not restart AN on its own on RK3568, so the link stays dead forever. Kicking ANRESTART here is the only way to recover. For a working link (link up), state->an_complete may still be set, but the function returns earlier at the "if (state->link)" check, so ANRESTART is never triggered on an active link. This should not cause unexpected link loss on any hardware. Regarding testing: - Jiawen Wu has tested this on Wangxun NICs and reported no regression (Tested-by tag included in the patch). - On RK3568 (Photonicat board), this fixes the SGMII link recovery issue. I agree that wider testing is beneficial, and I'm open to running more tests on different platforms if needed. However, given the condition is strictly limited to "link down + an_complete", the risk of disrupting an already-working link is minimal. Thanks, Coia