From: Emanuele Ghidoli emanuele.ghidoli@toradex.com
While the DP83867 PHYs report EEE capability through their feature registers, the actual hardware does not support EEE (see Links). When the connected MAC enables EEE, it causes link instability and communication failures.
The issue is reproducible with a iMX8MP and relevant stmmac ethernet port. Since the introduction of phylink-managed EEE support in the stmmac driver, EEE is now enabled by default, leading to issues on systems using the DP83867 PHY.
Call phy_disable_eee during phy initialization to prevent EEE from being enabled on DP83867 PHYs.
Link: https://e2e.ti.com/support/interface-group/interface/f/interface-forum/14452... Link: https://e2e.ti.com/support/interface-group/interface/f/interface-forum/65863... Fixes: 2a10154abcb7 ("net: phy: dp83867: Add TI dp83867 phy") Cc: stable@vger.kernel.org Signed-off-by: Emanuele Ghidoli emanuele.ghidoli@toradex.com --- drivers/net/phy/dp83867.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c index deeefb962566..36a0c1b7f59c 100644 --- a/drivers/net/phy/dp83867.c +++ b/drivers/net/phy/dp83867.c @@ -738,6 +738,12 @@ static int dp83867_config_init(struct phy_device *phydev) return ret; }
+ /* Although the DP83867 reports EEE capability through the + * MDIO_PCS_EEE_ABLE and MDIO_AN_EEE_ADV registers, the feature + * is not actually implemented in hardware. + */ + phy_disable_eee(phydev); + if (phy_interface_is_rgmii(phydev) || phydev->interface == PHY_INTERFACE_MODE_SGMII) { val = phy_read(phydev, MII_DP83867_PHYCTRL);
On Thu, Oct 23, 2025 at 04:48:53PM +0200, Emanuele Ghidoli wrote:
From: Emanuele Ghidoli emanuele.ghidoli@toradex.com
While the DP83867 PHYs report EEE capability through their feature registers, the actual hardware does not support EEE (see Links). When the connected MAC enables EEE, it causes link instability and communication failures.
The issue is reproducible with a iMX8MP and relevant stmmac ethernet port. Since the introduction of phylink-managed EEE support in the stmmac driver, EEE is now enabled by default, leading to issues on systems using the DP83867 PHY.
Call phy_disable_eee during phy initialization to prevent EEE from being enabled on DP83867 PHYs.
Link: https://e2e.ti.com/support/interface-group/interface/f/interface-forum/14452... Link: https://e2e.ti.com/support/interface-group/interface/f/interface-forum/65863...
Interesting statement this last one. "None of our gigabit PHYs support EEE operation today."
I wounder if any of the other TI PHY drivers need this fix?
Fixes: 2a10154abcb7 ("net: phy: dp83867: Add TI dp83867 phy") Cc: stable@vger.kernel.org Signed-off-by: Emanuele Ghidoli emanuele.ghidoli@toradex.com
Reviewed-by: Andrew Lunn andrew@lunn.ch
Andrew
Hello:
This patch was applied to netdev/net.git (main) by Jakub Kicinski kuba@kernel.org:
On Thu, 23 Oct 2025 16:48:53 +0200 you wrote:
From: Emanuele Ghidoli emanuele.ghidoli@toradex.com
While the DP83867 PHYs report EEE capability through their feature registers, the actual hardware does not support EEE (see Links). When the connected MAC enables EEE, it causes link instability and communication failures.
[...]
Here is the summary with links: - [v1] net: phy: dp83867: Disable EEE support as not implemented https://git.kernel.org/netdev/net/c/84a905290cb4
You are awesome, thank you!
On Thu, Oct 23, 2025 at 04:48:53PM +0200, Emanuele Ghidoli wrote:
While the DP83867 PHYs report EEE capability through their feature registers, the actual hardware does not support EEE (see Links). When the connected MAC enables EEE, it causes link instability and communication failures.
The issue is reproducible with a iMX8MP and relevant stmmac ethernet port. Since the introduction of phylink-managed EEE support in the stmmac driver, EEE is now enabled by default, leading to issues on systems using the DP83867 PHY.
Wasn't it enabled before? See commit 4218647d4556 ("net: stmmac: convert to phylink managed EEE support").
stmmac's mac_link_up() was:
- if (phy && priv->dma_cap.eee) { - phy_eee_rx_clock_stop(phy, !(priv->plat->flags & - STMMAC_FLAG_RX_CLK_RUNS_IN_LPI)); - priv->tx_lpi_timer = phy->eee_cfg.tx_lpi_timer; - stmmac_eee_init(priv, phy->enable_tx_lpi); stmmac_set_eee_pls(priv, priv->hw, true); - }
So, if EEE is enabled in the core synthesis, then EEE will be configured depending on what phylib says.
In stmmac_init_phy(), there was this:
- if (priv->dma_cap.eee) - phy_support_eee(phydev); - ret = phylink_connect_phy(priv->phylink, phydev);
So phylib was told to enable EEE support on the PHY if the dwmac core supports EEE.
So, from what I can see, converting to phylink managed EEE didn't change this. So what really did change?
On Sat, Oct 25, 2025 at 09:44:31AM +0100, Russell King (Oracle) wrote:
On Thu, Oct 23, 2025 at 04:48:53PM +0200, Emanuele Ghidoli wrote:
While the DP83867 PHYs report EEE capability through their feature registers, the actual hardware does not support EEE (see Links). When the connected MAC enables EEE, it causes link instability and communication failures.
The issue is reproducible with a iMX8MP and relevant stmmac ethernet port. Since the introduction of phylink-managed EEE support in the stmmac driver, EEE is now enabled by default, leading to issues on systems using the DP83867 PHY.
Wasn't it enabled before? See commit 4218647d4556 ("net: stmmac: convert to phylink managed EEE support").
stmmac's mac_link_up() was:
if (phy && priv->dma_cap.eee) {phy_eee_rx_clock_stop(phy, !(priv->plat->flags &STMMAC_FLAG_RX_CLK_RUNS_IN_LPI));priv->tx_lpi_timer = phy->eee_cfg.tx_lpi_timer;stmmac_eee_init(priv, phy->enable_tx_lpi); stmmac_set_eee_pls(priv, priv->hw, true);}So, if EEE is enabled in the core synthesis, then EEE will be configured depending on what phylib says.
In stmmac_init_phy(), there was this:
if (priv->dma_cap.eee)phy_support_eee(phydev);ret = phylink_connect_phy(priv->phylink, phydev);So phylib was told to enable EEE support on the PHY if the dwmac core supports EEE.
So, from what I can see, converting to phylink managed EEE didn't change this. So what really did change?
I suspect it is a change in board designs. iMX8MP EVB variants are using Realtek PHYs with the SmartEEE variant. Therefore, the MAC is not able to control LPI behavior. Designs based on the EVB design (with the Realtek PHY) are not affected. I mean, any bug on the MAC or software side will stay invisible.
Some new designs with special requirements for TSN, for example low-latency TI PHYs, are a different story. They promise "Extra low latency TX < 90ns, RX < 290ns" and also announce EEE support. These two promises are not compatible with each other anyway, and at the same time, even if LPI does work, it will most probably fail with the FEC driver. I do not know about STMMAC.
On Sat, Oct 25, 2025 at 11:19:25AM +0200, Oleksij Rempel wrote:
On Sat, Oct 25, 2025 at 09:44:31AM +0100, Russell King (Oracle) wrote:
On Thu, Oct 23, 2025 at 04:48:53PM +0200, Emanuele Ghidoli wrote:
While the DP83867 PHYs report EEE capability through their feature registers, the actual hardware does not support EEE (see Links). When the connected MAC enables EEE, it causes link instability and communication failures.
The issue is reproducible with a iMX8MP and relevant stmmac ethernet port. Since the introduction of phylink-managed EEE support in the stmmac driver, EEE is now enabled by default, leading to issues on systems using the DP83867 PHY.
Wasn't it enabled before? See commit 4218647d4556 ("net: stmmac: convert to phylink managed EEE support").
stmmac's mac_link_up() was:
if (phy && priv->dma_cap.eee) {phy_eee_rx_clock_stop(phy, !(priv->plat->flags &STMMAC_FLAG_RX_CLK_RUNS_IN_LPI));priv->tx_lpi_timer = phy->eee_cfg.tx_lpi_timer;stmmac_eee_init(priv, phy->enable_tx_lpi); stmmac_set_eee_pls(priv, priv->hw, true);}So, if EEE is enabled in the core synthesis, then EEE will be configured depending on what phylib says.
In stmmac_init_phy(), there was this:
if (priv->dma_cap.eee)phy_support_eee(phydev);ret = phylink_connect_phy(priv->phylink, phydev);So phylib was told to enable EEE support on the PHY if the dwmac core supports EEE.
So, from what I can see, converting to phylink managed EEE didn't change this. So what really did change?
I suspect it is a change in board designs. iMX8MP EVB variants are using Realtek PHYs with the SmartEEE variant. Therefore, the MAC is not able to control LPI behavior. Designs based on the EVB design (with the Realtek PHY) are not affected. I mean, any bug on the MAC or software side will stay invisible.
Some new designs with special requirements for TSN, for example low-latency TI PHYs, are a different story. They promise "Extra low latency TX < 90ns, RX < 290ns" and also announce EEE support. These two promises are not compatible with each other anyway, and at the same time, even if LPI does work, it will most probably fail with the FEC driver. I do not know about STMMAC.
What's annoying me is this "we spotted a change in the driver, we're going to blame that for our problems" attitude that there seems to be towards phylink.
When I make changes such as when porting a driver to a new facility, I try to do it with _no_ behavioural change. Yet, people still blame phylink for their problems. In 99% of cases, it turns out to be incorrect blame.
This commit description is stating that the conversion of stmmac to phylink-managed EEE changed the behaviour to default to enabling EEE. I claim that the driver _already_ defaulted to enabling EEE. So the commit description is nonsense, and just pulling at straws to justify the probem.
What I'm asking for is people to _properly_ investigate their problems rather than just looking at the commit history, and pulling out some random commit to blame, which invariably seems to be phylink related.
Having one's hard efforts constantly slated in this way is unhelpful.
linux-stable-mirror@lists.linaro.org
-
Andrew Lunn -
Emanuele Ghidoli -
Oleksij Rempel -
patchwork-bot+netdevbpf＠kernel.org -
Russell King (Oracle)