[PATCH net] net: stmmac: intel: don't reconfigure SerDes on unchanged mode

[PATCH net] net: stmmac: intel: don't reconfigure SerDes on unchanged mode

[Markus Breitenberger]

From: Markus Breitenberger <bre@keba.com>

intel_mac_finish() is registered as the phylink mac_finish() callback
for the Elkhart Lake SGMII ports. phylink calls mac_finish() at the end
of every major link reconfiguration, including the initial one during
probe, before any interface mode has actually changed.

The callback reprograms the shared ModPHY LCPLL through the PMC IPC and
then power-cycles the SerDes. On Elkhart Lake that ModPHY is also used
by the on-die AHCI SATA PHY. Running the reconfiguration during the
initial boot-time link-up disturbs the shared analog block while it is
still driving SATA, so the SATA link fails to train:

  ata1: SATA link down (SStatus 1 SControl 300)

The disk carrying the root filesystem is never detected and the system
hangs at rootwait. Ethernet itself comes up normally, which makes the
failure look unrelated to the network driver.

Firmware already programs the ModPHY for the configured interface, so
the reconfiguration is redundant unless the interface mode really
changes. Return early when the requested mode equals the current one.
This avoids touching the shared ModPHY (and the SATA PHY) during boot
while preserving runtime SGMII to 2500BASE-X switching, which still
sees a genuine mode change and reconfigures as before.

Fixes: a42f6b3f1cc1 ("net: stmmac: configure SerDes according to the interface mode")
Cc: stable@vger.kernel.org
Assisted-by: GitHub-Copilot:claude-opus-4.8
Signed-off-by: Markus Breitenberger <bre@keba.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index b8d467ba6d72..9a162831ca40 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -536,6 +536,15 @@ static int intel_mac_finish(struct net_device *ndev,
 	int max_regs = 0;
 	int ret = 0;
 
+	/* mac_finish() runs at the end of every major link reconfiguration,
+	 * including the initial one at probe, where the interface mode has
+	 * not actually changed. Reprogramming and power-cycling the SerDes is
+	 * only needed on a real mode change and is otherwise needlessly
+	 * disruptive, so skip it when the mode is unchanged.
+	 */
+	if (priv->plat->phy_interface == interface)
+		return 0;
+
 	ret = intel_tsn_lane_is_available(ndev, intel_priv);
 	if (ret < 0) {
 		netdev_info(priv->dev, "No TSN lane available to set the registers.\n");
-- 
2.55.0

Re: [PATCH net] net: stmmac: intel: don't reconfigure SerDes on unchanged mode

[Maxime Chevallier]

Hi Markus,

On 7/6/26 08:19, Markus Breitenberger wrote:
> From: Markus Breitenberger <bre@keba.com>
> 
> intel_mac_finish() is registered as the phylink mac_finish() callback
> for the Elkhart Lake SGMII ports. phylink calls mac_finish() at the end
> of every major link reconfiguration, including the initial one during
> probe, before any interface mode has actually changed.
> 
> The callback reprograms the shared ModPHY LCPLL through the PMC IPC and
> then power-cycles the SerDes. On Elkhart Lake that ModPHY is also used
> by the on-die AHCI SATA PHY. Running the reconfiguration during the
> initial boot-time link-up disturbs the shared analog block while it is
> still driving SATA, so the SATA link fails to train:
> 
>   ata1: SATA link down (SStatus 1 SControl 300)
> 
> The disk carrying the root filesystem is never detected and the system
> hangs at rootwait. Ethernet itself comes up normally, which makes the
> failure look unrelated to the network driver.
> 
> Firmware already programs the ModPHY for the configured interface, so
> the reconfiguration is redundant unless the interface mode really
> changes. Return early when the requested mode equals the current one.
> This avoids touching the shared ModPHY (and the SATA PHY) during boot
> while preserving runtime SGMII to 2500BASE-X switching, which still
> sees a genuine mode change and reconfigures as before.

One thing is that now we 'blindly' rely on the bootloader / fw having
correctly configured the initial interface.

From what I see the only configuration that's done is regarding the serdes
rate. Maybe instead the serdes interaction logic can be reworked so that you
query the serdes rate, see if you need to adjust it based on the selected
interface, and if so you re-configure it ?

Maxime

Re: [PATCH net] net: stmmac: intel: don't reconfigure SerDes on unchanged mode

[Andrew Lunn]

On Mon, Jul 06, 2026 at 08:19:54AM +0200, Markus Breitenberger wrote:
> From: Markus Breitenberger <bre@keba.com>
> 
> intel_mac_finish() is registered as the phylink mac_finish() callback
> for the Elkhart Lake SGMII ports. phylink calls mac_finish() at the end
> of every major link reconfiguration, including the initial one during
> probe, before any interface mode has actually changed.
> 
> The callback reprograms the shared ModPHY LCPLL through the PMC IPC and
> then power-cycles the SerDes. On Elkhart Lake that ModPHY is also used
> by the on-die AHCI SATA PHY. Running the reconfiguration during the
> initial boot-time link-up disturbs the shared analog block while it is
> still driving SATA, so the SATA link fails to train:
> 
>   ata1: SATA link down (SStatus 1 SControl 300)
> 
> The disk carrying the root filesystem is never detected and the system
> hangs at rootwait. Ethernet itself comes up normally, which makes the
> failure look unrelated to the network driver.
> 
> Firmware already programs the ModPHY for the configured interface, so
> the reconfiguration is redundant unless the interface mode really
> changes. Return early when the requested mode equals the current one.
> This avoids touching the shared ModPHY (and the SATA PHY) during boot
> while preserving runtime SGMII to 2500BASE-X switching, which still
> sees a genuine mode change and reconfigures as before.

What happens to the disk at runtime, rather than boot time, if it is
necessary to reconfigure the ModPHY?

I think i would prefer the machine fails to boot, rather than corrupt
its disk when i plug it into a different network switch.

	Andrew