[PATCH 1/1] net: spacemit: Check netif_carrier_ok when reading stats

[PATCH 1/1] net: spacemit: Check netif_carrier_ok when reading stats

[Chukun Pan]

Currently, when the interface is not linked up, reading the interface
stats will print several timeout logs. Add a netif_carrier_ok check to
the emac_stats_update function to avoid this situation:

root@OpenWrt:~# ubus call network.device status
[  120.365060] k1_emac cac81000.ethernet eth1: Read stat timeout

Fixes: bfec6d7f2001 ("net: spacemit: Add K1 Ethernet MAC")
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
---
 drivers/net/ethernet/spacemit/k1_emac.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/spacemit/k1_emac.c b/drivers/net/ethernet/spacemit/k1_emac.c
index c85dc742c404..d7972f247bcc 100644
--- a/drivers/net/ethernet/spacemit/k1_emac.c
+++ b/drivers/net/ethernet/spacemit/k1_emac.c
@@ -1080,8 +1080,10 @@ 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 */
+	if (!netif_running(priv->ndev) ||
+	    !netif_carrier_ok(priv->ndev) ||
+	    !netif_device_present(priv->ndev)) {
+		/* Not up or link, don't try to update */
 		return;
 	}
 
-- 
2.25.1

Re: [PATCH 1/1] net: spacemit: Check netif_carrier_ok when reading stats

[Andrew Lunn]

On Sun, Jan 18, 2026 at 06:00:00PM +0800, Chukun Pan wrote:
> Currently, when the interface is not linked up, reading the interface
> stats will print several timeout logs. Add a netif_carrier_ok check to
> the emac_stats_update function to avoid this situation:
> 
> root@OpenWrt:~# ubus call network.device status
> [  120.365060] k1_emac cac81000.ethernet eth1: Read stat timeout

What is the real issue here? That a clock is disabled? Can you test
the status of the clock, rather than adding yet more conditions to
this if ()?

     Andrew

Re: [PATCH 1/1] net: spacemit: Check netif_carrier_ok when reading stats

[Vivian Wang]

Hi Cunkun Pan:

On 1/18/26 18:00, Chukun Pan wrote:
> Currently, when the interface is not linked up, reading the interface
> stats will print several timeout logs. Add a netif_carrier_ok check to
> the emac_stats_update function to avoid this situation:

I am unable to reproduce this problem.

Can you elaborate on what you mean by "not linked up"? I couldn't
reproduce this on an unconnected interface.

I would also appreciate more information on this in general - full
kernel logs, hardware information (which board, what you were doing with
cables, etc...)

Thanks,
Vivian "dramforever" Wang

Re: [PATCH 1/1] net: spacemit: Check netif_carrier_ok when reading stats

[Chukun Pan]

Hi Andrew, Vivian,

> I am unable to reproduce this problem.
>
> Can you elaborate on what you mean by "not linked up"? I couldn't
> reproduce this on an unconnected interface.
>
> I would also appreciate more information on this in general - full
> kernel logs, hardware information (which board, what you were doing
> with cables, etc...)

I apologize for not expressing this question clearly.

I'm trying to run OpenWrt on OrangePi R2S and OrangePi RV2.
Unlike other Spacemit K1 boards, OrangePi uses the YT8531C PHY.

Read stats when the interface is not connected to a network cable:

root@OpenWrt:~# ethtool -S eth1
[   71.725539] k1_emac cac81000.ethernet eth1: Read stat timeout
NIC statistics:
     rx_drp_fifo_full_pkts: 0
     rx_truncate_fifo_full_pkts: 0

I just discovered that adding "motorcomm,auto-sleep-disabled" to disable
the sleep mode of the MotorComm PHY prevents the problem from occurring.

I will send a DT patch instead. Sorry for the noise.

Thanks,
Chukun

Re: [PATCH 1/1] net: spacemit: Check netif_carrier_ok when reading stats

[Andrew Lunn]

> root@OpenWrt:~# ethtool -S eth1
> [   71.725539] k1_emac cac81000.ethernet eth1: Read stat timeout
> NIC statistics:
>      rx_drp_fifo_full_pkts: 0
>      rx_truncate_fifo_full_pkts: 0
> 
> I just discovered that adding "motorcomm,auto-sleep-disabled" to disable
> the sleep mode of the MotorComm PHY prevents the problem from occurring.

This suggests that when the PHY stops the reference clock, the MAC
hardware stops working. It needs that clock to access
statistics. Keeping the clock ticking will increase power usage a
little.

I wounder if anything else stops working? There are some MACs whos DMA
engine stop working without the reference clock. That can cause
problems during both probe and remove, or open and close.

So it would be nice to have a better understanding of this. If this
turns out to be true, maybe a comment by this poll_read_timeout()
indicating if it does timeout, the PHY might be the problem.

	   Andrew

Re: [PATCH 1/1] net: spacemit: Check netif_carrier_ok when reading stats

[Vivian Wang]

On 1/19/26 23:09, Andrew Lunn wrote:
>> root@OpenWrt:~# ethtool -S eth1
>> [   71.725539] k1_emac cac81000.ethernet eth1: Read stat timeout
>> NIC statistics:
>>      rx_drp_fifo_full_pkts: 0
>>      rx_truncate_fifo_full_pkts: 0
>>
>> I just discovered that adding "motorcomm,auto-sleep-disabled" to disable
>> the sleep mode of the MotorComm PHY prevents the problem from occurring.
> This suggests that when the PHY stops the reference clock, the MAC
> hardware stops working. It needs that clock to access
> statistics. Keeping the clock ticking will increase power usage a
> little.

As per suggestion from Chukun, adding realtek,aldps-enable to the DTS on
BananaPi F3 (with, obviously, a Realtek PHY) also reproduces this
problem. So this is a good indication that it really is a problem with
this power saving thing.

> I wounder if anything else stops working? There are some MACs whos DMA
> engine stop working without the reference clock. That can cause
> problems during both probe and remove, or open and close.

At least DMA reset seems to work in this case, so it's probably not as
big of a problem, but at least I would conclude that the HW design
didn't have the reference clock stopping in mind. AFAICT from the DTS
files a bunch of other boards also have motorcomm,auto-sleep-disabled so
at least SpacemiT isn't alone in this.

> So it would be nice to have a better understanding of this. If this
> turns out to be true, maybe a comment by this poll_read_timeout()
> indicating if it does timeout, the PHY might be the problem.

I'll send a patch updating the comments and error prints.

Thanks,
Vivian "dramforever" Wang