[网络] ifconfig down掉的网口，插上网线网口灯依然亮？

1、软硬件环境

 环境1：

        硬件： 飞腾E2000Q ARM64 平台 + YT8521SH (phy) 

        软件： linux 4.19.246

 环境2：

        硬件： NXP T1042 PowerPC 平台  +  YT8521SH (phy) 

        软件： linux 4.1.35

备注：

1、环境1的网口是飞腾E2000Q 原生MAC + 裕太PHY YT8521SH 组成。

2、环境2的网口是 NXP T1042 原生MAC + 裕太PHY YT8521SH 组成。

3、两个环境中 phy的驱动（YT8521SH 的配置）使用同一版本，配置上没有差异。内核版本与MAC驱动不同。

2、问题现象

 环境1：飞腾E2000Q ARM64 平台 (异常)

不接网线时：网口up状态，ifconfig eth1 down 掉网口后，插上网线，link灯亮起。

 环境2：NXP T1042 PowerPC 平台（正常）

不接网线时：网口up状态，ifconfig eth1 down 掉网口后，插上网线，link灯灭的。

3、问题分析与排查

根据这个现象，初步判断可能是ifconfig down的时候，phy 没有suspend。下面我们来验证一下！

我们先看下正常的ifconfig down, 的函数调用流程是怎样的。

NXP T1042平台

---

还是利用利器ftrace来观察：

ifconfig eth1 up

cd /sys/kernel/debug/tracing
echo function > ./current_tracer
echo 1 > options/func_stack_trace
echo .yt8521_suspend > ./set_ftrace_filter
echo > trace
ifconfig eth1 down
cat trace

从上面过程中来看，ifconfig down 是通过ioctl 来和驱动交互的，会调用 MAC驱动的 ndo_stop() , 最终会调到 phy_suspend。

飞腾E2000Q平台

---

下面我们来看看问题设备，，使用ftrace 或者 驱动里加printk调试信息，发现不插网线的时候，ifconfig down , 并不会调用phy_suspend， 只有在有网线的时候，ifconfig down，才会调用 phy_suspend，而且这个过程没有ioctl的参与，完全是phy的状态机的行为。

 不插网线时， 我们重新 trace一下带 ioctl的流程，看看具体为什么没有调用 phy_suspend，根据MAC驱动，我们可以看出 ndo_stop函数具体是macb_close：

~/linux-ft $ grep ndo_stop -nR drivers/net/ethernet/phytium/
drivers/net/ethernet/phytium/macb_main.c:3430:	.ndo_stop		= macb_close,

这次我们 跟踪函数 macb_close向上的调用栈 ：

ifconfig eth1 up

cd /sys/kernel/debug/tracing
echo function > ./current_tracer
echo 1 > options/func_stack_trace
echo macb_close> ./set_ftrace_filter
echo > trace
ifconfig eth1 down
cat trace

 看来是飞腾E2000Q  MAC驱动中 ndo_stop时没有对phy进行操作。对phy的操作，完全有phy的状态机来控制，这点和T1042不同。我们看下 phy_state_machine 中的实现。针对该网卡，ifconfig down的时候，phy的状态会变成 PHY_HALTED 

 /**
  * phy_state_machine - Handle the state machine
  * @work: work_struct that describes the work to be done
  */
 void phy_state_machine(struct work_struct *work)
 {
    ........
         switch (phydev->state) {
         case PHY_DOWN:

    ........
        case PHY_HALTED:
                if (phydev->link) {
                        phydev->link = 0;
                        phy_link_down(phydev, true);
                        do_suspend = true;
                }
                break;

    ........
        if (needs_aneg)
                err = phy_start_aneg_priv(phydev, false);
        else if (do_suspend)
                phy_suspend(phydev);

    ........
}

 从上述代码里可以看到 当PHY的状态变成PHY_HALTED，意思就是要关闭网口，关闭PHY，但是只有当phy的link 从1变成0 才会进行 suspend操作，这里设计的感觉不太合理，应该在PHY的状态变成PHY_HALTED时，就对phy进行suspend, 这猜测是内核的一个bug，我们在内核的upstream上找找看, 

在最新版本内核上，执行git log drivers/net/phy/phy.c  扒拉扒拉看看有没有新的patch

果真找到了一个patch, 如下：

~/src/linus_torvalds/linux$ git show 95fb8bb3181bbe1ee87c95e91dff94f74f148c33
commit 95fb8bb3181bbe1ee87c95e91dff94f74f148c33
Author: Jian Shen <shenjian15@huawei.com>
Date:   Wed Aug 28 09:34:47 2019 +0800

    net: phy: force phy suspend when calling phy_stop
    
    Some ethernet drivers may call phy_start() and phy_stop() from
    ndo_open() and ndo_close() respectively.
    
    When network cable is unconnected, and operate like below:
    step 1: ifconfig ethX up -> ndo_open -> phy_start ->start
    autoneg, and phy is no link.
    step 2: ifconfig ethX down -> ndo_close -> phy_stop -> just stop
    phy state machine.
    
    This patch forces phy suspend even phydev->link is off.
    
    Signed-off-by: Jian Shen <shenjian15@huawei.com>
    Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index f3adea9ef400..0acd5b49f450 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -911,8 +911,8 @@ void phy_state_machine(struct work_struct *work)
                if (phydev->link) {
                        phydev->link = 0;
                        phy_link_down(phydev, true);
-                       do_suspend = true;
                }
+               do_suspend = true;
                break;
        }

至此，解决。

4、总结

• 不同网卡驱动实现不一样，这里包括不同平台CPU原生MAC驱动实现，虽然使用同一颗phy，但由于MAC不同，phy的现象也可能会有差异。
• 遇到内核问题，可以多去upstream上看看有无相关patch，自己遇到的问题，可能是别人已踩过坑。