Ethernet PHY软件复位失效排查：从MDIO寄存器到状态机的深度解析

最近在调试一块板卡时碰到一个典型的“软复位失效”问题：Ethernet PHY 的软件复位操作，写寄存器后读回来，看着值是生效了，但PHY就是没按预期重新初始化，链路始终起不来。这类问题在嵌入式网络开发里非常常见，尤其是当你手里没有调试器、只能靠MDIO读写寄存器来做诊断的时候，会特别折腾人。今天就把这个问题的排查思路和背后原理完整记录下来，希望对正在和PHY较劲的同行有点帮助。

1. 先搞清楚“软件复位”到底在复位什么

Ethernet PHY 的软件复位，通常指的是通过管理接口（MDIO/MDC）往 PHY 的寄存器 0（Basic Mode Control Register，BMCR）的 bit 15 写入 1，让 PHY 内部逻辑恢复到上电默认状态。这个操作看起来很简单，实际上涉及到数字逻辑、时钟域、状态机等多个层面的协作，任何一个环节没配合好，都会出现“写了等于没写”的现象。

从 PHY 内部结构来看，软件复位真正影响的是MAC 接口（如 RGMII、SGMII）的状态机、MII 管理接口的控制逻辑、以及自动协商（Auto-Negotiation）状态机。它并不会去复位那些由电源管理或晶振电路决定的硬件状态，比如 PLL 的锁定状态、参考时钟的稳定性检测结果。理解这一点很重要，因为很多人以为软件复位跟硬件上电复位（Hardware Reset）是等价行为，实际上两者差异很大。

硬件复位引脚（通常叫 RESET_N，低电平有效）一般直接连到 PHY 的复位电路，它会强制所有内部寄存器回到芯片出厂默认值，同时重新锁定 PLL、重新检测时钟。而软件复位只作用于数字逻辑部分，并且复位完成后需要重新配置那些被“打回原形”的寄存器（比如 LED 配置、中断掩码、环回模式等）。这只是铺垫，更重要的是，软复位操作的正确执行，必须满足几个先决条件：MDIO 接口能稳定读写、时钟已经稳定、电源已经进入正常范围。

这里的核心矛盾点是：你默认“能读写寄存器”就代表 PHY 工作正常，但很多时候 MDIO 读写正常恰恰掩盖了更深层的状态问题。比如你写 BMCR 的 bit15=1，读回来也是 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 5（Auto-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 14：Loopback，环回模式
• bit 13：Speed Selection（速度选择高位）
• bit 12：Auto-Negotiation Enable，自动协商使能
• bit 8：Duplex Mode，全双工/半双工
• bit 6：Restart Auto-Negotiation，重启自动协商
• bit 5：Isolate，隔离模式
• bit 3：Speed Selection LSB

软复位之后，PHY 会把这些位全部置为默认值，通常是：自动协商使能（bit 12 = 1）、隔离模式关闭（bit 5 = 0）、速度选择位恢复为芯片默认。而 BMSR（寄存器 1）是只读状态寄存器，它会在软件复位完成后更新相应的能力位和状态位，尤其是 bit 5（Auto-Negotiation Complete）和 bit 2（Link 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 总线本身的正确性

先不要写任何复位命令，只做两件事：

• 读寄存器 2（PHY Identifier Register High）、寄存器 3（PHY Identifier Register Low），确认能读出正常值。
• 读寄存器 1（BMSR），确认 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-phy@4 { 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.9
• SoC: Allwinner H3（内置 GMAC，支持 RGMII）
• PHY: Realtek RTL8211F，地址 0x01
• 问题：系统启动后，网络不工作，ifconfig eth0 up提示链路断开，但通过 MDIO 读寄存器 1，发现 Link Status 位（bit 2）是 0

我的排查流程是典型的：

1. 先读寄存器 0（BMCR），得到的值为 0x1000，说明自动协商已经开启。
2. 手动写软复位：

// 伪代码 phy_write(0x01, 0x00, 0x8000); mdelay(10); val = phy_read(0x01, 0x00); printf("BMCR = 0x%04x\n", val);

读出来 BMCR 为 0x1000，证明软复位已经自清零完成。但是此时 Link Status 依然是 0，没有链路建立。

3. 用示波器抓到 RTL8211F 的 RGMII RX_CLK 和 TX_CLK 没有任何时钟输出，排除 PHY 问题？其实不是，PHY 本身参考时钟是外部 25MHz，通过内部 PLL 倍频出 125MHz，如果 PLL 没锁定，RGMII 时钟自然没有输出。

4. 检查寄存器 0x1C（RTL8211F 的 PHY 特定状态寄存器），发现 bit 13（PLL Lock）为 0，意味着 PLL 没有锁定。这才意识到问题不在软复位，而在于 PHY 的 PLL 需要参考时钟稳定后一段时间才能锁定，而我们的代码在系统启动后 50ms 就执行了软复位，此时 PLL 根本没有进入锁定状态。

5. 解决办法：上电后等待至少 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 时常用的工具，都是低成本、高性价比的方案，很适合个人开发者和小团队。

工具只是辅助，调试 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 的软复位难题。