[<prev] [next>] [day] [month] [year] [list]
Message-Id: <20260120-k1-ethernet-clarify-stat-timeout-v1-1-108cf928d1b3@iscas.ac.cn>
Date: Tue, 20 Jan 2026 12:19:23 +0800
From: Vivian Wang <wangruikang@...as.ac.cn>
To: Andrew Lunn <andrew+netdev@...n.ch>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Yixun Lan <dlan@...too.org>
Cc: Chukun Pan <amadeus@....edu.cn>,
Michael Opdenacker <michael.opdenacker@...tcommit.com>,
netdev@...r.kernel.org, linux-riscv@...ts.infradead.org,
spacemit@...ts.linux.dev, linux-kernel@...r.kernel.org,
Vivian Wang <wangruikang@...as.ac.cn>
Subject: [PATCH net-next] net: spacemit: Clarify stat timeout comments and
messages
Someone did run into this timeout in the wild [1], and it turns out to
be related to the PHY reference clock stopping.
Improve the comments and error message prints around this to reflect the
better understanding of how this could happen. This patch doesn't fix
the problem, but should direct anyone running into it in the future to
know it is probably a PHY problem, and have a better idea what to do.
Link: https://lore.kernel.org/r/20260119141620.1318102-1-amadeus@jmu.edu.cn/ # [1]
Signed-off-by: Vivian Wang <wangruikang@...as.ac.cn>
---
* Chukun: If you think changing the DTS for the PHY is appropriate, you
can send the DTS patch separately - that one should go through the
spacemit SoC tree.
FWIW, the same timeout thing also happens on the vendor provided OS
images for the OrangePi RV2, and AFAICT at least the statistics part is
not recoverable.
So until/unless we manage to get more information on how this works
under the hood, I think we just don't bother handling the case where the
PHY can just stop running, since the hardware certainly doesn't seem to
expect it.
---
drivers/net/ethernet/spacemit/k1_emac.c | 23 +++++++++++++++++------
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/spacemit/k1_emac.c b/drivers/net/ethernet/spacemit/k1_emac.c
index 220eb5ce7583..387f26ff7714 100644
--- a/drivers/net/ethernet/spacemit/k1_emac.c
+++ b/drivers/net/ethernet/spacemit/k1_emac.c
@@ -1099,7 +1099,14 @@ static int emac_read_stat_cnt(struct emac_priv *priv, u8 cnt, u32 *res,
100, 10000);
if (ret) {
- netdev_err(priv->ndev, "Read stat timeout\n");
+ /*
+ * If you run into this, one possibility is that even though the
+ * interface is up the PHY may have stopped its clock anyway for
+ * power saving. This MAC doesn't like that, so configure your
+ * PHY to not do that.
+ */
+ dev_err_ratelimited(&priv->ndev->dev,
+ "Read stat timeout. PHY clock stopped?\n");
return ret;
}
@@ -1148,16 +1155,20 @@ static void emac_stats_update(struct emac_priv *priv)
assert_spin_locked(&priv->stats_lock);
if (!netif_running(priv->ndev) || !netif_device_present(priv->ndev)) {
- /* Not up, don't try to update */
+ /*
+ * Not up, don't try to update. If the PHY is stopped, reading
+ * stats would time out.
+ */
return;
}
for (i = 0; i < sizeof(priv->tx_stats) / sizeof(*tx_stats); i++) {
/*
- * If reading stats times out, everything is broken and there's
- * nothing we can do. Reading statistics also can't return an
- * error, so just return without updating and without
- * rescheduling.
+ * If reading stats times out anyway, the stat registers will be
+ * stuck, and we can't really recover from that.
+ *
+ * Reading statistics also can't return an error, so just return
+ * without updating and without rescheduling.
*/
if (emac_tx_read_stat_cnt(priv, i, &res))
return;
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20260120-k1-ethernet-clarify-stat-timeout-d221fcd3aaa8
Best regards,
--
Vivian "dramforever" Wang
Powered by blists - more mailing lists