最近在调试一块板卡时碰到一个典型的“软复位失效”问题Ethernet PHY 的软件复位操作写寄存器后读回来看着值是生效了但PHY就是没按预期重新初始化链路始终起不来。这类问题在嵌入式网络开发里非常常见尤其是当你手里没有调试器、只能靠MDIO读写寄存器来做诊断的时候会特别折腾人。今天就把这个问题的排查思路和背后原理完整记录下来希望对正在和PHY较劲的同行有点帮助。1. 先搞清楚“软件复位”到底在复位什么Ethernet PHY 的软件复位通常指的是通过管理接口MDIO/MDC往 PHY 的寄存器 0Basic Mode Control RegisterBMCR的 bit 15 写入 1让 PHY 内部逻辑恢复到上电默认状态。这个操作看起来很简单实际上涉及到数字逻辑、时钟域、状态机等多个层面的协作任何一个环节没配合好都会出现“写了等于没写”的现象。从 PHY 内部结构来看软件复位真正影响的是MAC 接口如 RGMII、SGMII的状态机、MII 管理接口的控制逻辑、以及自动协商Auto-Negotiation状态机。它并不会去复位那些由电源管理或晶振电路决定的硬件状态比如 PLL 的锁定状态、参考时钟的稳定性检测结果。理解这一点很重要因为很多人以为软件复位跟硬件上电复位Hardware Reset是等价行为实际上两者差异很大。硬件复位引脚通常叫 RESET_N低电平有效一般直接连到 PHY 的复位电路它会强制所有内部寄存器回到芯片出厂默认值同时重新锁定 PLL、重新检测时钟。而软件复位只作用于数字逻辑部分并且复位完成后需要重新配置那些被“打回原形”的寄存器比如 LED 配置、中断掩码、环回模式等。这只是铺垫更重要的是软复位操作的正确执行必须满足几个先决条件MDIO 接口能稳定读写、时钟已经稳定、电源已经进入正常范围。这里的核心矛盾点是你默认“能读写寄存器”就代表 PHY 工作正常但很多时候 MDIO 读写正常恰恰掩盖了更深层的状态问题。比如你写 BMCR 的 bit151读回来也是 1但 PHY 内部根本没有执行复位序列这种“假成功”是最坑的。2. 软件复位不工作的常见原因逐项排查我在实际调试过程中总结出了软复位失效最常见的三个层面第一个是时序与寄存器访问冲突第二个是硬件复位与软件复位相互干扰第三个是 PHY 芯片对软复位内部的特殊实现。我会逐一展开说每个层面都写上我踩过的具体坑。2.1 寄存器写入被 PHY 自动协商状态机“吞掉”这是最常见也最容易被忽视的场景。PHY 在上电后会自动进入 Auto-Negotiation 流程这个过程内部有独立的状态机在运行。如果你在这期间写入 BMCR.15 复位位某些 PHY 芯片的设计会认为这是一个无效指令或者把这次写操作当成“自动协商期间的特殊命令”给忽略掉。我有一个具体的例子某款国产 PHY 芯片型号就不点名了上电后立刻去写软复位寄存器读回来的值确实已经是 0x8000但是 PHY 并没有真正复位。查阅芯片手册的勘误表发现芯片要求复位指令必须在自动协商启动后的 100μs 窗口内写入才有效如果错过了这个窗口需要先往 AN 控制寄存器寄存器 4写入一个“重启自动协商”的触发位再回到寄存器 0 操作复位。这就不再是简单的寄存器写入问题了而是一个芯片状态机调度问题。解决办法也很实际软件复位前先确保 MDIO 时钟频率不要超过手册规定值常见 2.5MHz 或 25MHz同时往寄存器 0 写复位位之前可以先读一次寄存器 1状态寄存器确认 PHY 已经完成上电初始化比如 BMSR 的 bit 5Auto-Negotiation Complete已经置位。等到这个位变了基本可以认为 PHY 内部进入了稳定状态这时候软复位通常能一次成功。2.2 软复位后对寄存器值变化的误判很多人排查软复位问题时喜欢用“写完后立刻读回”来判断是否成功。这里有一个很深的陷阱BMCR 的 bit 15 是一个自清零位Self-Clearing Bit也就是说PHY 内部一旦接收复位指令这个位很快就会自动恢复为 0。你如果在写完复位命令后立刻去读会发现读回来的值是 0这并不代表复位失败反而说明复位已经接受了。反过来讲如果写完复位后你反复去读取这个 bit 15 始终是 1那十有八九是复位没有正常执行——因为内部逻辑没收到复位信号自清零机制也就不会触发。这个“自清零”机制的实际实现不同厂家差别很大。有的芯片在 100ns 内就完成清零有的会卡在 10μs 左右还有的芯片在 MDIO 读取操作的同一周期内完成清零。就拿我测过的几款芯片来说TI 的 DP83822 大约是 8μs 清零Marvell 的 88E1512 大概 1μs而瑞昱的 RTL8211F 则是 2.5μs。这个时间参数太重要了因为你现在写了个软复位紧接着就去配置其它寄存器比如 PHYADR、LED 配置如果这些配置在复位序列完全结束前就被写入很可能会被 PHY 内部的复位逻辑冲掉或者写入失败。所以我在代码里软复位后通常会加一个超过 10ms 的延时这个时间对大多数 PHY 芯片来说是安全的然后再读取状态寄存器确认复位完成最后才重新初始化其它寄存器。这个 10ms 怎么来的我做了一个简单计算大部分 PHY 完成软复位内部逻辑需要 1μs~2ms 之间留出 5 倍以上的裕量10ms 已经足够覆盖绝大多数芯片又不会让系统启动时间明显变长。如果是严谨的产品应该去查具体芯片手册的 Soft Reset Time 参数但我做开发板驱动时统一用 10ms实测稳定。2.3 硬件上下拉配置导致的复位引脚电平冲突这一条看似跟“软件复位”无关却是我实际排查中最容易忽略的一类问题。很多 PHY 芯片支持通过硬件引脚如 PHYAD[4:0]、MODE[2:0]来配置上电默认工作模式软件复位会把寄存器恢复到这个默认值。如果这些引脚的上拉/下拉电阻焊接有问题或者被外部控制器比如 FPGA、SoC复用后错误驱动了电平就会出现一个诡异现象软复位后 PHY 进入了一个不期望的模式比如把接口从 RGMII 变成了 MII或者把 PHY 地址从 0x04 变成了 0x00。这个时候你再用原来的 PHY 地址去读写寄存器当然全部失败然后你会误判为“软件复位不工作”。我记得有一次调试采用 Marvell 88E1512地址配置引脚 PHYAD[4:0] 通过 10kΩ 电阻上拉成 0b00100也就是地址 4。板子第一版跑得好好的改版后换了一批电阻批次焊接后测出来地址变成了 0b00101。因为 MDIO 总线上挂了两颗从设备我拿原地址去读怎么读都是 0xFFFF总线没有设备应答当时还以为是 PHY 被软复位“复位坏了”。后来换了个思路用总线扫描的方式把 0x00~0x1F 全部扫了一遍才发现从设备地址漂移到了 5。重新核对原理图发现 PHYAD[0] 的走线旁边新增了一根时钟信号串扰导致引脚电平不稳定。这个问题最终通过调整 PCB 间距和增加弱下拉电阻解决但从现象上看它的确表现为“软件复位后设备消失”也算是个不大不小的坑。3. 从寄存器层面深挖BMCR、BMSR 与 PHY 控制逻辑如果你确认时钟、电源、引脚配置都没有问题但软复位依旧不工作那就要逐步深入到 PHY 内部的寄存器交互逻辑了。这个环节需要你对着 PHY datasheet 的寄存器表把复位后的状态变化梳理清楚而不是看一眼 BMCR 就下结论。3.1 BMCR 与 BMSR 的关键位演变BMCR寄存器 0除了 bit 15 是软复位外还有几个和复位密切相关的位bit 14Loopback环回模式bit 13Speed Selection速度选择高位bit 12Auto-Negotiation Enable自动协商使能bit 8Duplex Mode全双工/半双工bit 6Restart Auto-Negotiation重启自动协商bit 5Isolate隔离模式bit 3Speed Selection LSB软复位之后PHY 会把这些位全部置为默认值通常是自动协商使能bit 12 1、隔离模式关闭bit 5 0、速度选择位恢复为芯片默认。而 BMSR寄存器 1是只读状态寄存器它会在软件复位完成后更新相应的能力位和状态位尤其是 bit 5Auto-Negotiation Complete和 bit 2Link Status。调试时建议把目光从“复位是否生效”转移到“复位后的状态是否符合预期”。写一个辅助脚本软复位后周期性读取寄存器 1记录从复位开始到 Auto-Negotiation Complete 置位的时间差。这个时间差如果超过芯片手册给定的上限说明 PHY 内部有异常。举个例子正常情况下 DP83822 从软复位到 AN 完成大概需要 50ms 左右如果读出来一直是 0那就要检查是不是 MDC 时钟不稳定导致 PHY 内部状态机没有正确触发。这里有一个细节值得注意MDC 时钟是什么时候提供的有些设计在系统启动阶段SoC 的 MDC 时钟还没有使能软件代码通过 GPIO 模拟 MDIO 去读写。这种情况下PHY 的软件复位命令虽然被正确发送了但是 MDC 的占空比和频率不稳定PHY 内部的同步逻辑很容易丢状态。我建议用 GPIO 模拟时MDC 低电平和高电平的延时都尽量大于 200ns而且保证 MDIO 数据在 MDC 上升沿之前已经稳定这套软复位时序比用硬件 MDIO 控制器要敏感得多。3.2 PHY 芯片规格差异导致的复位时序陷阱不同厂家的 PHY软件复位内部行为差异很大这不是一个标准化流程。Marvell 的很多型号在软复位期间会屏蔽 MDIO 接口的访问也就是说你不光写了复位命令还要等待它解除屏蔽才能继续读寄存器。而 TI 的部分型号则会在软复位期间对 MDIO 读写正常响应但返回的数据是复位前的旧值。这些差异对排查路径影响很明显。比如我调试过一个 Realtek 的 RTL8211F手册里明确说软复位的时间是 2.5ms但在实际应用中我发现如果软复位命令发出后立刻读取寄存器 1总是返回 0xFFFF这不符合手册描述。后来咨询 FAE原因是芯片内部的 MDIO 同步器需要依赖 PHY 的 25MHz 参考时钟而上电初期参考时钟还没完全稳定导致 MDIO 模块没有进入工作状态。所以软复位前一定等参考时钟稳定或者先做一次“假读”来唤醒 MDIO 逻辑。如果你使用的 PHY 支持扩展寄存器如 Marvell 的 0x10~0x1E可以尝试通过扩展寄存器来读取芯片的 Revision ID 或者软复位状态位。这能帮你区分PHY 只是软复位没有执行还是复位执行了但某些功能块没起来。我踩过一次坑以为软复位整个失效结果只是 PHY 内部的 SerDes串行器/解串器没有重新初始化导致 SGMII 接口协商失败但 MDIO 寄存器一切正常。这种情况靠加延时是没用的必须在软复位后重新配置 SerDes 的控制寄存器把速率重新锁定。4. 软复位失败的系统级调试实操流程讲到实操我建议你按下面的“五步法”排查每一步都有明确的产出不要一上来就怀疑芯片坏了。这五个步骤是我在一个量产项目里归纳出来的现在每次遇到 PHY 问题都按这个顺序走效率高得多。4.1 第一步验证 MDIO 总线本身的正确性先不要写任何复位命令只做两件事读寄存器 2PHY Identifier Register High、寄存器 3PHY Identifier Register Low确认能读出正常值。读寄存器 1BMSR确认 bit 0 或 bit 2 有合理的状态。如果读出来的全是 0xFFFF说明 PHY 根本没有应答。这就不是软复位的问题而是 MDIO 地址、总线电气或者 PHY 供电问题。如果读出来是 0x0000那有可能 PHY 芯片已经损坏或者处于隔离模式Isolate这时候 MDIO 仍然可以响应一部分寄存器读取。具体来说当 PHY 的 BMCR bit 5 被置 1 后它会把本身从 MII/RMII/RGMII 接口隔离出来MDIO 接口还是可以访问寄存器 2/3 的但访问其它寄存器可能会异常。所以如果读 ID 正常但状态寄存器全是 0要重点检查是不是之前某次配置把隔离位置位了。在这个阶段我习惯用一个通用的 PHY 寄存器读取脚本可以用 Python pyftdi 控制 FT2232H或者用 i2c-tools 的 /dev/mem 直接操作 SoC 的 MDIO 控制器把所有 32 个寄存器的值读出来存放在一个 log 文件里。这个 log 在后续排查中价值很大因为软复位前后的寄存器对比是最直接的证据。4.2 第二步在极小系统中测试软复位如果你确认 MDIO 通信正常但软复位无效果建议搭建一个最小测试环境一颗 PHY、一颗 MCU、一个晶振、三个 LED可选用飞线连接 MDC、MDIO 和中断引脚。这样做的好处是排除了 PCB 上其它器件的干扰比如 FPGA 配置冲突、电源毛刺、以及 SoC 内部 PHY 驱动反复读写造成的竞态。在极小系统里启动后只做一件事往 BMCR 写 0x8000。然后等 10ms读取寄存器 0 和寄存器 1。如果此时读到 BMCR 为 0x1000自动协商使能默认开启而 BMSR 显示 Link Status 变化说明软复位成功了。如果在这么干净的硬件环境里软复位仍然无效那这颗芯片的软复位行为可能和你预想的不一样需要启用调试工具如示波器抓 MDIO 波形确认命令在电平层面是否正确发送了。抓 MDIO 波形值得单独说一句很多人以为代码里写对了寄存器操作硬件上就一定会产生正确信号。实际上 GPIO 模拟 MDIO 时引脚方向切换、时序翻转都容易出问题特别是如果用了 open-drain 输出而外部上拉电阻阻值太大上升沿会很慢导致 PHY 采样到错误电平。用示波器抓波形时重点看 MDIO 信号在 MDC 上升沿前后的建立时间和保持时间多数 PHY 要求至少 10ns 的建立时间和 10ns 的保持时间如果你的波形达不到需要调整 GPIO 翻转顺序或者换硬件 MDIO 控制器。4.3 第三步核查电源、时钟与复位引脚的“三角稳定区”这一步是排障经验里最重要的一部分。很多时候软复位失效的根因既不在 MDIO 软件时序也不在 PHY 芯片本身而在于芯片工作条件没有同时满足“电源稳定、时钟稳定、复位引脚无效电平”。我所谓的“三角稳定区”是指PHY 供电电压通常是 3.3V 或 1.8V/1.0V已经达到标称值的 90% 以上参考时钟如 25MHz已经输出稳定的方波Reset 引脚已经释放从低电平变为高电平。这三个条件必须同时满足一段时间大部分 PHY 手册要求 5ms~50ms软件复位指令才能被正确解析。我在调试中实际遇到过一个很隐蔽的问题电源芯片的 enable 引脚与 SoC 的 GPIO 相连SoC 启动脚本里这个 GPIO 输出高电平但是电源芯片本身有软启动过程电压上升斜率比较慢。结果就是软件已经检测到 SoC 网络接口就绪开始跑 PHY 驱动并发出软复位指令但 PHY 的电源还没完全到位。此时 MDIO 接口有时能响应因为 PHY 内部一部分数字逻辑已经在工作在较低电压下但复位状态机没有正常工作导致软复位命令被忽略。等到电源完全稳定后PHY 已经跳过了复位窗口链路初始化就无法完成。解决办法很直白驱动初始化时先做一个“电源稳定等待”不要仅仅依赖 SoC 的启动时序。最靠谱的方式是读取 PHY 的供电监测寄存器部分芯片有或者直接测量电源芯片的 Power Good 信号并接到 SoC 的中断或 GPIO 上。如果硬件不支持这些也可以通过在驱动里读 PHY 的芯片版本 ID 来确认内部逻辑是否已经完成初始化比如 TI 的 DP83822 在电源稳定后寄存器 0x0010 会返回固定的值。4.4 第四步对比软复位与硬复位的行为差异这一步能帮你精确定位是 PHY 本身问题还是 SoC 驱动问题。具体做法是在同一个板子上先触发一次硬件复位通过对 RESET_N 引脚输出低电平再释放观察 PHY 是否正常初始化并建立链路等链路稳定后再执行一次软件复位看链路是否会断开并重新建立。如果硬件复位工作正常但软件复位不工作问题大概率在 MDIO 总线时序、寄存器访问顺序或者 PHY 的软复位实现上。如果硬件复位本身也不正常那你就要回头查电源、时钟和复位引脚的硬件设计了。在我调试的那块板卡上硬件复位正常链路起来只要 3 秒但软件复位后链路完全没有断开LED 不闪这就是典型的“写入未生效”或“生效但未执行”。此时我再做一个更细的动作软复位后立刻写一个非默认值到寄存器 0比如把自动协商关掉写 0x0000然后读回来确认是否写入成功。如果写入成功但链路状态没变化说明 PHY 内部状态机卡住了需要额外读取 PHY specific status registers比如寄存器 0x1A 或 0x1B来看具体卡在哪个状态。如果写入不成功那问题在 MDIO 接口时钟同步或 PHY 地址选择上重新检查 MDC/MDIO 的电气连接。4.5 第五步用 Linux PHY 驱动框架做协议级验证如果你用的是 Linux 系统嵌入式 Linux 很常见可以通过 phylib 提供的接口做底层验证不需要自己写裸机程序。在 Linux 命令行下用 ethtool 或者直接在用户态调用 ioctl 操作 MDIO 总线可以快速验证软复位行为。这里举一个例子在设备树里 PHY 的节点通常是这样表示的mdio0 { phy0: ethernet-phy4 { reg 4; reset-gpios gpio0 12 GPIO_ACTIVE_LOW; reset-deassert-us 10000; }; };系统起来后你可以用下面这条命令强制触发 PHY 重新协商ethtool -r eth0这个命令会触发 phylib 层面的软复位流程即往 BMCR 写重新协商命令你可以用devmem直接读取 MDIO 寄存器来观察软件复位后的寄存器状态。但要注意Linux phylib 不一定每次都执行“完整软复位”写 BMCR bit15有些版本的驱动只是调用 genphy_restart_aneg重启自动协商。所以如果你的目的是验证软复位最好直接用 devmem 写# 假设 MDIO 控制器基址和 PHY 地址已知 devmem 0x... 32 0x80008000 # 这一行示意具体取决于你的平台更规范的验证方式是在用户态通过 phy 驱动的 debugfs 接口读取寄存器值cat /sys/kernel/debug/mdio_bus/stmmac-0/4/registers这个命令会列出 PHY 地址 4 上所有寄存器的当前值可以作为软复位前后对比的依据。如果系统没有打开 debugfs 或者 PHY 驱动不支持那你只能回到裸机/用户态直接操作寄存器的方式或者写一个小的内核模块来调用 phy_read/phy_write 函数。5. 一个从零复现软复位问题的完整案例前面全是方法论这一节我讲一个具体案例大家有兴趣可以在自己的板子上复现一下。这个案例来自一个使用 Allwinner H3 加 RTL8211F 的板卡。背景信息系统Linux 4.9SoC: Allwinner H3内置 GMAC支持 RGMIIPHY: Realtek RTL8211F地址 0x01问题系统启动后网络不工作ifconfig eth0 up提示链路断开但通过 MDIO 读寄存器 1发现 Link Status 位bit 2是 0我的排查流程是典型的先读寄存器 0BMCR得到的值为 0x1000说明自动协商已经开启。手动写软复位// 伪代码 phy_write(0x01, 0x00, 0x8000); mdelay(10); val phy_read(0x01, 0x00); printf(BMCR 0x%04x\n, val);读出来 BMCR 为 0x1000证明软复位已经自清零完成。但是此时 Link Status 依然是 0没有链路建立。用示波器抓到 RTL8211F 的 RGMII RX_CLK 和 TX_CLK 没有任何时钟输出排除 PHY 问题其实不是PHY 本身参考时钟是外部 25MHz通过内部 PLL 倍频出 125MHz如果 PLL 没锁定RGMII 时钟自然没有输出。检查寄存器 0x1CRTL8211F 的 PHY 特定状态寄存器发现 bit 13PLL Lock为 0意味着 PLL 没有锁定。这才意识到问题不在软复位而在于 PHY 的 PLL 需要参考时钟稳定后一段时间才能锁定而我们的代码在系统启动后 50ms 就执行了软复位此时 PLL 根本没有进入锁定状态。解决办法上电后等待至少 100ms或者定期读取寄存器 0x1C 的 PLL Lock bit 直到为 1然后再做软复位。修改驱动后网络接口在启动后约 250ms 内正常建立链路。这个案例给我们的教训是软复位命令本身没问题但 PHY 内部的模拟电路PLL还没准备好导致整个链路建立失败。你如果只看 MDIO 寄存器会以为软件复位没生效其实它早已生效只是后续的数据通路没起来。6. 软复位失败排查中的常见错误操作整理几个我在各种项目和技术支持中常见的错误操作大家可以对照一下自己的代码避免走弯路。复位后立即配置寄存器很多人写完软复位加一个 1ms 的 mdelay 就开始配置 RGMII 时序、LED 模式、中断使能。但 PHY 的寄存器空间在软复位后的前 1~2ms 内可能仍处于内部重载状态对 MDIO 写操作响应不稳定配置很容易丢。不同的 PHY 差异很大建议至少等待 10ms然后读取你要配置的寄存器地址确认复位前的值已经被清掉再写入新值。把软件复位当成硬件复位的替代品硬件复位可以强制 PHY 重新采样引脚配置如 PHYAD[4:0]、MODE[2:0]而软件复位不能。如果你改变了硬件引脚配置想通过软件复位来让 PHY 采用新配置这辈子都不可能。必须用硬件复位或者重新上电。忽略 PHY 的时钟源依赖有些 PHY 芯片支持从 MAC 侧接收参考时钟比如 RMII 模式下的 REF_CLK。如果软复位之后MAC 侧的 REF_CLK 被配置为输出低电平因为复位会初始化 MAC 时钟控制器PHY 就会失去时钟源MDIO 接口虽然还能响应因为 MDIO 的时钟源可以独立于 REF_CLK但 PHY 的数据通路无法工作。这时候你读所有寄存器都正常但就是没有链路。盲目修改 PHY 驱动而不做波形验证如果软复位失败直接去改驱动里的延时和时序而不是先抓波形确认 MDIO 是否真实发出去大概率是在瞎猜。至少先用示波器抓 MDC、MDIO 两个引脚确认命令帧确实发送了并且 PHY 有响应帧再考虑改代码。我见过太多工程师改了几十版驱动最后发现是 PHY 芯片焊接虚焊导致 MDIO 时钟被拉低。7. 高性价比的 PHY 软复位调试工具推荐最后推荐几个我调试 PHY 时常用的工具都是低成本、高性价比的方案很适合个人开发者和小团队。工具用途优点适用场景逻辑分析仪如 Saleae Logic 16抓取 MDC/MDIO 波形分析命令帧便宜、直观、易用排查软复位命令是否真实发出、PHY 地址是否匹配示波器带宽至少 100MHz抓取 MDIO 电平建立/保持时间、电源启动波形能分析模拟信号、上升沿质量问题排查电源时序、时钟稳定性、MDIO 电平异常树莓派 python-smbus 或 SPIDEV通过 I2C/SPI 转 MDIO 控制器访问 PHY 寄存器快速验证寄存器读写逻辑、可离线复现问题在原型阶段验证 PHY 行为不依赖目标 SoC 是否启动Linux debugfs / ethtool在系统内观测 PHY 状态和寄存器值无需额外硬件适合产品联调阶段验证驱动层的复位行为、自动协商状态工具只是辅助调试 PHY 软复位问题真正重要的是理解寄存器背后的状态机行为。如果你连“自清零位”都没搞清楚就算给你十台示波器你也不知道该测什么波形。8. 经验总结与防坑建议写了这么多其实可以浓缩成三条实践原则第一软复位前一定要等 PHY 的电源和时钟完全稳定不要一上电就急着复位。最好是通过读芯片 ID 寄存器或者 PLL 锁定状态来确认。如果硬件没有提供 Power Good 信号给 SoC就在驱动里固定加 50ms 延迟千万不要觉得浪费这一下能省去大量排查时间。第二软复位后不要仅依赖读回 BMCR 的 bit 15 来判断是否成功因为自清零机制会在短时间内把该位清掉。更可靠的方式是检查链路状态BMSR bit 2或自动协商状态BMSR bit 5如果这些状态位在复位后发生了预期变化才算真正成功。第三遇到“软复位不工作”时第一时间先复查硬件配置PHY 地址引脚的上下拉、复位引脚的时序、参考时钟的波形、电源轨的电压。软件寄存器操作问题一般比较容易通过代码检查发现反而是硬件细节最容易被忽略也是最能折腾人的。根据我个人的经验PHY 软复位问题十有八九都能归结到“时序”或者“状态机冲突”这两类只要你能把 MDIO 波形、寄存器状态变化、以及 PHY datasheet 里的时序图三者结合起来看问题一般都能在一天内定位。希望这篇文章能帮你少走弯路在实际项目中快速解决 Ethernet PHY 的软复位难题。