[参考译文] DP83867IR：自动协商完成时出现 PHY 链路错误

您好、Min、

我同意这是奇怪的行为。 您能否确认正在使用哪个内核版本的 Linux？ 命令'uname -r'将显示在终端上。  

问题：

1. 此问题是否仅在保留几天后才出现、是否可重现？
   1. 如果我们可以重现该问题、我们是否可以尝试设置寄存器0x0 = 1340？ 这将重新启动自动协商。
2. 我了解恢复方法、但插入/拔下电缆无法解决问题？  
3. 此问题会影响多少个电路板？

此致、

Alvaro

尊敬的 Alvaro：

感谢您的答复。 内核版本为 5.10.72

1、是的、我只发现在 以太网线断开运行几天时发生这种情况。 我认为这是可重现的、它发生了3次。  

设置寄存器0x0 = 1340没有帮助

2、插拔无法解决此问题

3、这是原型板、我们 这里只有两块板、 它们都受此问题的影响。

4、我已尝试将0x4000和0x8000写入寄存器0x1f、它们都无法正常工作。  但是,在 建立链路的正常情况下,在我将0x8000写入寄存器0x1f 后, PHY 没有重新启动自动协商过程并停止工作。 我必须下调 ifconfig eth0才能恢复、这是否正常？

您好、Min、

您如何确定链路建立或断开？ 我们正在检查 ethtool 还是需要终端消息？ 我要检查寄存器0x1是否与该终端显示的内容相匹配。 如果 ethtool 显示链路断开、但寄存器0x1 = 796 D. 则可能是软件问题。 如果 TH 工具和寄存器0x1 = 794 9. 则可能是硬件问题。  

此致、

Alvaro

是的、我们首先通过内核驱动程序日志确定它、内核没有运行到 phy 中断、然后我们使用 ethtool 和 phytool、它们都显示链路已断开。

寄存器0x1是7969、而我们可以看到链路 LED 亮起、数据 LED 闪烁。  

您好、Min、

感谢您的确认。 在正常工作和非正常工作的情况下、我们可以执行寄存器转储吗？

在以下情况下读取寄存器0x0-0x1F、6E 和6F：

1. 在以太网电缆断开连接的情况下启动电路板
2. 以太网电缆已连接  
3. 工作时断开电阻器

如果您可以在 Excel 文件中收集此数据、这将使我更容易查看。

请注意、寄存器0x6e 和0x6f 是扩展寄存器、 请参阅此常见问题解答以了解如何访问它们。

此致、

Alvaro

尊敬的 Alvaro：

我已找到原因、它与 strap 配置无关。 对于 PHY 自动协商已完成 、但  等待我们的器件读取并清除协商 完成 中断。  因此 Phy 正在谈判中完成,但链接没有东方状态。  该中断是 GPIO 边沿触发、一旦发生 未由 CPU 处理的触发事件、中断线路将保持该电平、不再触发中断。 我删除了以太网 GPIO 中断并转向轮询方法。 那么它是固定的。 您有什么建议？

您好、Min、

我很高兴您发现了这个问题！ 请确认我的理解是否正确。

您将引脚44用作中断。 这是通过启用寄存器0x12 (MICR)中的中断来完成的。 您已经启用了自动协商完成中断(寄存器0x12 = 0800)。 连接电缆后、PHY 完成自动协商、因此寄存器0x13 (ISR)的第11位变为高电平。 这意味着 PHY 在连接到 CPU 的引脚44上置位低电平信号。 您认为 CPU 对该信号不执行任何操作、因此会卡住？  

如果您再次配置中断方法、那么读取寄存器0x13 (这将清除中断)是否可以解决该问题？

您需要中断吗？ 如果您可以使用轮询方法、为什么从一开始就使用了中断？

此致、

Alvaro  

尊敬的 Alvaro：

是的、 读取寄存器0x13将修复该问题。 测量内部信号后、一旦信号 转换速率不快、就会   出现另一个传入中断、CPU 将错过此中断、然后会出现问题。

因为从我们的初始设计来看、使用中断通知 CPU 处理以太网操作比经常让 CPU 安排和轮询寄存器状态要好。  

您好、Min、

理解、 使用中断总是比轮询更可取。 现在、在我看来、PHY 的行为符合预期、问题出在处理器上。 您是否认为来自 PHY 的中断信号压摆率较慢、这会导致处理器出现问题？

此致、

Alvaro