[PATCH RFC net-next] net: stmmac: provide flag to disable EEE
Russell King (Oracle)
linux at armlinux.org.uk
Mon Feb 2 14:23:45 PST 2026
On Mon, Feb 02, 2026 at 08:54:52PM +0200, Ovidiu Panait wrote:
>
> Hi Russell,
>
> On 11/24/25 1:27 PM, Russell King (Oracle) wrote:
> > Some platforms have problems when EEE is enabled, and thus need a way
> > to disable stmmac EEE support. Add a flag before the other LPI related
> > flags which tells stmmac to avoid populating the phylink LPI
> > capabilities, which causes phylink to call phy_disable_eee() for any
> > PHY that is attached to the affected phylink instance.
> >
> > iMX8MP is an example - the lpi_intr_o signal is wired to an OR gate
> > along with the main dwmac interrupts. Since lpi_intr_o is synchronous
> > to the receive clock domain, and takes four clock cycles to clear, this
> > leads to interrupt storms as the interrupt remains asserted for some
> > time after the LPI control and status register is read.
> >
> > This problem becomes worse when the receive clock from the PHY stops
> > when the receive path enters LPI state - which means that lpi_intr_o
> > can not deassert until the clock restarts. Since the LPI state of the
> > receive path depends on the link partner, this is out of our control.
> > We could disable RX clock stop at the PHY, but that doesn't get around
> > the slow-to-deassert lpi_intr_o mentioned in the above paragraph.
> >
> > Previously, iMX8MP worked around this by disabling gigabit EEE, but
> > this is insufficient - the problem is also visible at 100M speeds,
> > where the receive clock is slower.
> >
> > There is extensive discussion and investigation in the thread linked
> > below, the result of which is summarised in this commit message.
> >
>
> We are seeing the same lpi_intr_o interrupt storm on the Renesas RZ/V2H
> EVK (dwmac-renesas-gbeth.c). On this platform, lpi_intr_o is routed as a
> separate, dedicated interrupt line to the CPU rather than being OR'd
> with the main DWMAC interrupt as on iMX8MP. This corresponds to the
> "eth_lpi" interrupt in the stmmac bindings:
> """
> - description: The interrupt that occurs when Rx exits the LPI state
> const: eth_lpi
> """
>
> Looking through the other glue drivers/device-trees, it looks to me that
> every platform that defines a separate "eth_lpi" irq might have the
> interrupt storm problem.
That is highly likely.
> To fix this issue on these platforms, rather than disabling EEE
> altogether, would it be possible to just not request the eth_lpi
> interrupt and let EEE continue to work? Perhaps a new flag could let
> each platform decide.
Yes, because lpi_intr_o serves no purpose from a software point of
view - see the commit message below for the details. I do like
removing code from stmmac :)
> If not, maybe this patch could be merged to add the flag that disables
> EEE and I will just send a patch to disable EEE on our platforms as well.
We still need the flag to disable EEE for platforms where lpi_intr_o is
logically OR'd with the other interrupts, so there's no way to ignore
its persistent assertion.
8<===
From: "Russell King (Oracle)" <rmk+kernel at armlinux.org.uk>
Subject: [PATCH net-next] net: stmmac: remove support for lpi_intr_o
The dwmac databook for v3.74a states that lpi_intr_o is a sideband
signal which should be used to ungate the application clock, and this
signal is synchronous to the receive clock. The receive clock can run
at 2.5, 25 or 125MHz depending on the media speed, and can stop under
the control of the link partner. This means that the time it takes to
clear is dependent on the negotiated media speed, and thus can be 8,
40, or 400ns after reading the LPI control and status register.
It has been observed with some aggressive link partners, this clock
can stop while lpi_intr_o is still asserted, meaning that the signal
remains asserted for an indefinite period that the local system has
no direct control over.
The LPI interrupts will still be signalled through the main interrupt
path in any case, and this path is not dependent on the receive clock.
This, since we do not gate the application clock, and the chances of
adding clock gating in the future are slim due to the clocks being
ill-defined, lpi_intr_o serves no useful purpose. Remove the code which
requests the interrupt, and all associated code.
Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/common.h | 1 -
.../net/ethernet/stmicro/stmmac/dwmac-intel.c | 4 ---
.../ethernet/stmicro/stmmac/dwmac-loongson.c | 7 ----
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 2 --
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 36 -------------------
.../ethernet/stmicro/stmmac/stmmac_platform.c | 8 -----
include/linux/stmmac.h | 1 -
7 files changed, 59 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
index 1c5a4af85b58..d26e8a063022 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -394,7 +394,6 @@ enum request_irq_err {
REQ_IRQ_ERR_SFTY,
REQ_IRQ_ERR_SFTY_UE,
REQ_IRQ_ERR_SFTY_CE,
- REQ_IRQ_ERR_LPI,
REQ_IRQ_ERR_WOL,
REQ_IRQ_ERR_MAC,
REQ_IRQ_ERR_NO,
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index aad1be1ec4c1..92d77b0c2f54 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -719,7 +719,6 @@ static int intel_mgbe_common_data(struct pci_dev *pdev,
/* Setup MSI vector offset specific to Intel mGbE controller */
plat->msi_mac_vec = 29;
- plat->msi_lpi_vec = 28;
plat->msi_sfty_ce_vec = 27;
plat->msi_sfty_ue_vec = 26;
plat->msi_rx_base_vec = 0;
@@ -1177,8 +1176,6 @@ static int stmmac_config_multi_msi(struct pci_dev *pdev,
res->irq = pci_irq_vector(pdev, plat->msi_mac_vec);
if (plat->msi_wol_vec < STMMAC_MSI_VEC_MAX)
res->wol_irq = pci_irq_vector(pdev, plat->msi_wol_vec);
- if (plat->msi_lpi_vec < STMMAC_MSI_VEC_MAX)
- res->lpi_irq = pci_irq_vector(pdev, plat->msi_lpi_vec);
if (plat->msi_sfty_ce_vec < STMMAC_MSI_VEC_MAX)
res->sfty_ce_irq = pci_irq_vector(pdev, plat->msi_sfty_ce_vec);
if (plat->msi_sfty_ue_vec < STMMAC_MSI_VEC_MAX)
@@ -1294,7 +1291,6 @@ static int intel_eth_pci_probe(struct pci_dev *pdev,
*/
plat->msi_mac_vec = STMMAC_MSI_VEC_MAX;
plat->msi_wol_vec = STMMAC_MSI_VEC_MAX;
- plat->msi_lpi_vec = STMMAC_MSI_VEC_MAX;
plat->msi_sfty_ce_vec = STMMAC_MSI_VEC_MAX;
plat->msi_sfty_ue_vec = STMMAC_MSI_VEC_MAX;
plat->msi_rx_base_vec = STMMAC_MSI_VEC_MAX;
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index ed0b534d8d7b..d66ae6ea4df5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -442,13 +442,6 @@ static int loongson_dwmac_dt_config(struct pci_dev *pdev,
res->wol_irq = res->irq;
}
- res->lpi_irq = of_irq_get_byname(np, "eth_lpi");
- if (res->lpi_irq < 0) {
- dev_err(&pdev->dev, "IRQ eth_lpi not found\n");
- ret = -ENODEV;
- goto err_put_node;
- }
-
ret = device_get_phy_mode(&pdev->dev);
if (ret < 0) {
dev_err(&pdev->dev, "phy_mode not found\n");
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 012b0a477255..aafd8c39be63 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -31,7 +31,6 @@ struct stmmac_resources {
void __iomem *addr;
u8 mac[ETH_ALEN];
int wol_irq;
- int lpi_irq;
int irq;
int sfty_irq;
int sfty_ce_irq;
@@ -297,7 +296,6 @@ struct stmmac_priv {
int wol_irq;
u32 gmii_address_bus_config;
struct timer_list eee_ctrl_timer;
- int lpi_irq;
u32 tx_lpi_timer;
bool tx_lpi_clk_stop;
bool eee_enabled;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 7a451ae19f50..7925575fb348 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3734,10 +3734,6 @@ static void stmmac_free_irq(struct net_device *dev,
free_irq(priv->sfty_ce_irq, dev);
fallthrough;
case REQ_IRQ_ERR_SFTY_CE:
- if (priv->lpi_irq > 0 && priv->lpi_irq != dev->irq)
- free_irq(priv->lpi_irq, dev);
- fallthrough;
- case REQ_IRQ_ERR_LPI:
if (priv->wol_irq > 0 && priv->wol_irq != dev->irq)
free_irq(priv->wol_irq, dev);
fallthrough;
@@ -3795,24 +3791,6 @@ static int stmmac_request_irq_multi_msi(struct net_device *dev)
}
}
- /* Request the LPI IRQ in case of another line
- * is used for LPI
- */
- if (priv->lpi_irq > 0 && priv->lpi_irq != dev->irq) {
- int_name = priv->int_name_lpi;
- sprintf(int_name, "%s:%s", dev->name, "lpi");
- ret = request_irq(priv->lpi_irq,
- stmmac_mac_interrupt,
- 0, int_name, dev);
- if (unlikely(ret < 0)) {
- netdev_err(priv->dev,
- "%s: alloc lpi MSI %d (error: %d)\n",
- __func__, priv->lpi_irq, ret);
- irq_err = REQ_IRQ_ERR_LPI;
- goto irq_error;
- }
- }
-
/* Request the common Safety Feature Correctible/Uncorrectible
* Error line in case of another line is used
*/
@@ -3952,19 +3930,6 @@ static int stmmac_request_irq_single(struct net_device *dev)
}
}
- /* Request the IRQ lines */
- if (priv->lpi_irq > 0 && priv->lpi_irq != dev->irq) {
- ret = request_irq(priv->lpi_irq, stmmac_interrupt,
- IRQF_SHARED, dev->name, dev);
- if (unlikely(ret < 0)) {
- netdev_err(priv->dev,
- "%s: ERROR: allocating the LPI IRQ %d (%d)\n",
- __func__, priv->lpi_irq, ret);
- irq_err = REQ_IRQ_ERR_LPI;
- goto irq_error;
- }
- }
-
/* Request the common Safety Feature Correctible/Uncorrectible
* Error line in case of another line is used
*/
@@ -7752,7 +7717,6 @@ static int __stmmac_dvr_probe(struct device *device,
priv->dev->irq = res->irq;
priv->wol_irq = res->wol_irq;
- priv->lpi_irq = res->lpi_irq;
priv->sfty_irq = res->sfty_irq;
priv->sfty_ce_irq = res->sfty_ce_irq;
priv->sfty_ue_irq = res->sfty_ue_irq;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 8979a50b5507..5c9fd91a1db9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -725,14 +725,6 @@ int stmmac_get_platform_resources(struct platform_device *pdev,
stmmac_res->wol_irq = stmmac_res->irq;
}
- stmmac_res->lpi_irq =
- platform_get_irq_byname_optional(pdev, "eth_lpi");
- if (stmmac_res->lpi_irq < 0) {
- if (stmmac_res->lpi_irq == -EPROBE_DEFER)
- return -EPROBE_DEFER;
- dev_info(&pdev->dev, "IRQ eth_lpi not found\n");
- }
-
stmmac_res->sfty_irq =
platform_get_irq_byname_optional(pdev, "sfty");
if (stmmac_res->sfty_irq < 0) {
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 5199451dd0bc..2620f0217f88 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -300,7 +300,6 @@ struct plat_stmmacenet_data {
int int_snapshot_num;
int msi_mac_vec;
int msi_wol_vec;
- int msi_lpi_vec;
int msi_sfty_ce_vec;
int msi_sfty_ue_vec;
int msi_rx_base_vec;
--
2.47.3
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
More information about the linux-arm-kernel
mailing list