工具与软件：
您好！
我的客户正在测试连接到 AM6232的两个 DP83867以太网 PHY 收发器的运行情况、遇到以下问题：
-如果他们在 Linux 控制台中运行"# ifconfig eth0 down", eth1也将关闭。
-这种症状只出现在他们生产的几个样本板中的某些板上。
请告知我们是否有任何 H/W 因素可能导致该问题、例如 DP83867以太网 PHY 收发器的引脚连接或电阻器或电容器连接。
谢谢你。
JH
你(们)好
感谢您的热情支持。
我们有客户提供的其他更新。
下面是我上周末与您分享的 DTS 文件。 该 dts 基于 TI SDK 使用的 Linux 内核 dts。
e2e.ti.com/.../ally_5F00_mcpu.dts.txt
这是 eth0停机而 eth1是问题电路板时现象的行为描述。
当‘在 shell 中执行"ifconfig eth0 down"时、似乎会在每个进程的最后一个信息部分将内核的网络 phy 驱动程序设置为电源完成模式。
这意味着 Linux 内核 phy 驱动程序将设置 BMCR 的位11、这将导致下面提到的问题。
另外、即使您使用 GPIO 引脚将 PHY-0置于复位状态、也会发生这种现象。
在该状态下读取 PHY-1的寄存器时、会读取异常值。
由于 PHY 状态寄存器返回异常值、因此 eth1网络关闭并且也无法正常运行。
我很难知道实际的 PHY 读取/写入操作是问题还是 PHY 内部的状态是问题。 但是、PHY 内部的状态似乎发生了改变、而不是读取/写入操作、因为即使 PHY-1的 MDIO 总线被分离为 GPIO、该状态也是相同的。
要消除这种现象、请将位11设置为0、或者在使用 GPIO 进行复位时、释放复位并重新初始化网络、它将正常工作。
换句话说、在断电模式下、似乎使用寄存器或通过 PHY 的复位 SIGINAL 进入复位状态。
到目前为止、状态如上所示。
此外、我无法与他们共享日志、但根据他们的说法、他们确认他们将总线信息或驱动程序与设备树中的 eth0和 eth1分开加载、并且他们没有向 PHY 驱动程序添加任何代码来单独控制 eth0和 eth1、如下所示。
静态 int phy_suspend (结构 phy_device * phydev)
｛
if (strcmp (phydev->attached_dev->name、"eth1")== 0){
// eth1 phy 未断电
返回0；
}
//其他 PHY 已断电
PHY_MODIFY (phydev、MII_BMCR、BMCR_POWERDOWN、BMCR_POWERDOWN)；
返回0；
}
如果我需要修改代码以便能够为各个接口控制 PHY 驱动程序、我会喜欢提供一份指南、
如果有一种测试方法(如 ethertool 或 sysfs)来单独控制它、请提供指导。
谢谢。
此致、
插孔
