乙太網驅動流程淺析（三） ifconfig的 19錯誤最底層分析 Author：張昺華 Email：[email protected] Time：2019年3月23日星期六 此文也在我的個人公眾號以及《Linux內核之旅》上有發表： "乙太網驅動流程淺析（三） ifconfig的 19錯誤最底層分析" ...
乙太網驅動流程淺析（三）-ifconfig的-19錯誤最底層分析
Author：張昺華
Email：[email protected]
Time：2019年3月23日星期六
此文也在我的個人公眾號以及《Linux內核之旅》上有發表：乙太網驅動流程淺析（三）-ifconfig的-19錯誤最底層分析
很喜歡一群人在研究技術，一起做有意思的東西，一起分享技術帶給我們的快樂，也希望中國有更多的人熱愛技術，喜歡一起研究、分享技術，然後可以一起用我們的技術來做一些好玩的東西，可以為這個社會創造一些東西來改善人們的生活。
如下是本人調試過程中的一點經驗分享，乙太網驅動架構畢竟涉及的東西太多，如下僅僅是針對載入流程和圍繞這個問題產生的分析過程和驅動載入流程部分，並不涉及乙太網協議層的數據流程分析。
【硬體環境】 Imx6ul
【Linux kernel版本】 Linux4.1.15
【乙太網phy】 Realtek8201f
1. 乙太網流程分析跟蹤
1.1 ifconfig的-19錯誤最底層分析
看了後我們知道是fec_enet_mii_probe函數返回的-19，繼續跟蹤進去：
哈哈，看到這裡答案出來了，-19就是這裡返回的，也就是說phy_dev是NULL
那為什麼呢？我們跟進去看下，of_phy_connect，功能註釋已經寫的很清楚了
Connect to the phy described in the device tree，從設備樹上獲取phy的相關描述信息，路徑：drivers/of/of_mdio.c
既然phy_device是空的，也就是說struct phy_device *phy = of_phy_find_device(phy_np);
沒有從這裡面拿到phy_device
看下如下兩個函數
這裡我需要解釋下了，bus_find_device(&mdio_bus_type, NULL, phy_np, of_phy_match);
從bus匯流排上找到device，也就是我們的phy_device，
如果找到就返回phy_device，否則就返回NULL
這個bus是指mdio_bus_type，如下：
1.2 乙太網硬體知識
那mdio又是什麼呢？這就是乙太網的知識了，我們看下乙太網的硬體接法：
如下內容轉自：https://blog.csdn.net/fun_tion/article/details/70270632
1.概述
MII即“媒體獨立介面”，也叫“獨立於介質的介面”。它是IEEE-802.3定義的乙太網行業標準。它包括一個數據介面，以及一個MAC和PHY之間的管理介面。RMII全稱為“簡化的媒體獨立介面”，是IEEE-802.3u標準中除MII介面之外的另一種實現。（此處內容來源於網路）
2.獨立於介質的介面（MII）
獨立於介質的介面(MII)用於MAC與外接的PHY互聯，支持10Mbit/s和100Mbit/s數據傳輸模式。MII的信號線如下圖所示：
MII_TX_CLK：發送數據使用的時鐘信號，對於10M位/s的數據傳輸，此時鐘為2.5MHz，對於100M位/s的數據傳輸，此時鐘為25MHz。
MII_RX_CLK：接收數據使用的時鐘信號，對於10M位/s的數據傳輸，此時鐘為2.5MHz，對於100M位/s的數據傳輸，此時鐘為25MHz。
MII_TX_EN：傳輸使能信號，此信號必需與數據前導符的起始位同步出現，併在傳輸完畢前一直保持。
MII_TXD[3:0]：發送數據線，每次傳輸4位數據，數據在MII_TX_EN信號有效時有效。MII_TXD[0]是數據的最低位，MII_TXD[3]是最高位。當MII_TX_EN信號無效時，PHY忽略傳輸的數據。
MII_CRS：載波偵聽信號，僅工作在半雙工模式下，由PHY控制，當發送或接收的介質非空閑時，使能此信號。 PHY必需保證MII_CRS信號在發生衝突的整個時間段內都保持有效，不需要此信號與發送/接收的時鐘同步。
MII_COL：衝突檢測信號，僅工作在半雙工模式下，由PHY控制，當檢測到介質發生衝突時，使能此信號，並且在整個衝突的持續時間內，保持此信號有效。此信號不需要和發送/接收的時鐘同步。
MII_RXD[3:0]：接收數據線，每次接收4位數據，數據在MII_RX_DV信號有效時有效。MII_RXD[0]是數據的最低位，MII_RXD[3]是最高位。當MII_RX_EN無效，而MII_RX_ER有效時，MII_RXD[3:0]數據值代表特定的信息(請參考表194)。
MII_RX_DV：接收數據使能信號，由PHY控制，當PHY準備好數據供MAC接收時，使能該信號。此信號必需和幀數據的首位同步出現，並保持有效直到數據傳輸完成。在傳送最後4位數據後的第一個時鐘之前，此信號必需變為無效狀態。為了正確的接收一個幀，有效電平不能滯後於數據線上的SFD位出現。
MII_RX_ER：接收出錯信號，保持一個或多個時鐘周期(MII_RX_CLK)的有效狀態，表明MAC在接收過程中檢測到錯誤。具體錯誤原因需配合MII_RX_DV的狀態及MII_RXD[3:0]的數據值。
3.精簡的獨立於介質的介面（RMII）
精簡的獨立於介質介面(RMII)規範減少了乙太網通信所需要的引腳數。根據IEEE802.3標準，MII介面需要16個數據和控制信號引腳，而RMII標準則將引腳數減少到了7個。RMII具有以下特性：
時鐘信號需要提高到50MHz。
MAC和外部的乙太網PHY需要使用同樣的時鐘源
使用2位寬度的數據收發
RMII的信號線如下圖所示：
如上內容轉自：https://blog.csdn.net/fun_tion/article/details/70270632
1.3 Mdio匯流排沒有找到phy_device
接下來回歸到軟體層面，那乙太網的通信收發數據包就是使用MDC/MDIO這樣的硬體介面
軟體的介面是：mdiobus_read與mdiobus_write
那這塊最終的read / write的實現函數在哪裡呢？去乙太網控制器drvier里看就好了fec_main.c中：
回歸到剛剛的-19錯誤最終發現是phy_device為NULL了，也就是在mdio bus上沒有找到對應的phy_device，那麼從這裡我們可以猜想註冊的時候是否根本就沒註冊進去呢？或者是註冊成功了後，在某個階段phy_device消失了？帶著這個疑問我們就要看下乙太網控制器載入的流程了。
4. 網址分享
http://stackoverflow.com/questions/5308090/set-ip-address-using-siocsifaddr-ioctl
http://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.commtrf2/ioctl_socket_control_operations.htm
https://lkml.org/lkml/2017/2/3/396
linux PHY驅動
http://www.latelee.org/programming-under-linux/linux-phy-driver.html
Linux PHY幾個狀態的跟蹤
http://www.latelee.org/programming-under-linux/linux-phy-state.html
第十六章PHY -基於Linux3.10
https://blog.csdn.net/shichaog/article/details/44682931
```
