1、测试环境
硬件：NXP LS1046A ARM64平台 + 88E1548P
软件：linux 4.19.26 + linux 5.10.35
环境说明：88E1548P 是一个QSGMII 的 phy 芯片，LS1046A CPU 提供4个GMAC 与 88E1548P 连接，就是4个千兆网口。
2、具体现象
eth7发包，速度600Mbps , 此时通过eth7 ping对端ip , 不断插拔eth7的网线，几分钟后会出现 无法ping通的情况。（eth7是QSGMII的第一个port）
QSGMII 4个port 现象一样，都存在此问题。
eth7不通时，其余port正常通信
不跑流量，暂未复现。
ifconfig eth7 down/up 软复位无法恢复
对整个QSGMII芯片 硬复位，恢复。
修改eth7 为100M/10M FULL 没有恢复，改为100M/10M HALF 恢复。
3、测试步骤
执行命令 tcpreplay -i eth7 -l 2000 -M 600 udp.pcap 向对端发包
(注意修改udp.pcap 目的MAC地址)
通过eth7 ping对端ip ， 不断插拔eth7的网线，观察ping的情况
4、问题分析
(1) 遇到像网口不通这种问题，一般要先判断是MAC还是PHY出现了问题，一种简单的方法是复位，一般来说，复位谁可以恢复，大概率就是谁的问题。经过测试，只有下面第一种硬复位有效。看着出问题时phy 挂掉了。
(2）升级内核中的phy驱动，使用最新版本内核linux6.2中的marvell驱动，问题依然存在。
(3)可以通过 各种loopback来定位问题，出现问题时哪种loopback 不通了。一般有 utp 一端的loopback , QSGMII 一端的loopback，不过本次测试，当出现问题时，loopback是正常的，使用phy 发包，无论发给MAC侧还是发给网线对端一侧都是可以收到包的。这就有点奇怪，应该是QSGMII中的一个port 某一块逻辑死掉了。
(4) 查找芯片的勘误手册，看看是否是已知bug。此处注意，手册一定要准确的，应为marvell 88e1548 和 88e1548p 手册和勘误都是不同的，如果看错手册，bug可能就发现不了，我就是犯了这个低级错误，因为没有太关注具体的芯片信号，只是看原理图简单的记下型号，也不知道有两种芯片的区分。查了下区别：
手册上也是有区别的。
根据 MV-S302250-00_88E1548P_Release-Notes.pdf 7.3章节 发现88E1548P MACsec/PTP 功能有个bug 比较相近。经过测试，是它，是它，就是它！
我们工程当中实际用不到这个功能，所以把这个功能禁掉了。测试正常。
