Linux Mii management/mdio子系统分析之二 mdio总线-设备-驱动模型分析

? ? ? 接着上篇文章继续分析mdio子系统，本章主要介绍mdio子系统的驱动模型，当然了介绍mdio子系统的驱动模型，就绕不开linux系统设备-总线-驱动模型，所有的总线类的驱动，基本上都可以理解为继承自linux系统设备-总线-驱动模型。

本篇主要介绍如下几部分的内容：

一、总线-设备-驱动-控制器模型分析

二、总线定义

三、class定义

?

一、总线-设备-驱动-控制器模型分析

? ? ? ?针对驱动模型而言，基本上通过其数据结构的定义及关联，即可窥知一二（结构体一般封装了数据与方法，基本上熟悉数据结构间的关联，也就对其模型有了理解）。下面我们先建立phy_device、phy_driver、mdio_bus、mii_bus、device、device_driver等数据结构之间的关联，介绍该子系统的驱动模型，接着再对具体的数据结构进行分析。

如下图即为这些数据结构间的关联，主要涉及两个方面：

1. mdio子系统的驱动模型，主要继承于linux系统的设备-总线-驱动模型，因此通过继承device、device_driver数据结构的定义，完成了mdio_bus_type、device、device_driver的关联，并使用设备-总线-驱动提供的方法完成这些数据结构间的绑定与解绑操作（device_register、driver_register、bus->probe、bus->remove等接口）；
2. 与之前介绍的mmc、spi、i2c驱动模型类似，mdio驱动模型也定义了phy_device、phy_driver、mii_bus之间的关联，phy_device通过其成员变量，完成了与mii_bus、phy_driver之间的关联：
   1. phy_device通过其bus指针，可获取其所依附的mii management，即可使用mii_bus提供给的read/write方法；
   2. phy_device通过其drv指针，可获取该device对应的driver，可实现对自己的驱动操作；

?phy_device通过与mii_bus、phy_driver的关联，即可实现针对该phy_device的命令设置、状态获取等操作，因此在网口驱动实现时，每一个网口对应的net_device均通过其私有指针，绑定对应的phy_device，通过该phy_device类型变量，即可获取该网口对应phy的信息。

?

以上即是mdio子系统的驱动模型，该子系统的数据结构（phy_device、phy_driver、mdio_bus_type）通过继承linux设备-总线-驱动模型的结构体，即可借助其方法完成针对phy_device的probe/remove操作，实现驱动与设备的绑定与解绑操作。下面我们分析下这几个数据结构的定义。

?

struct mii_bus

该数据结构对应一个mii management控制器的抽象，定义的数据和方法说明如下：
?

id：表示该mii_bus的id信息（如针对ti cpsw的mii_bus，其id值为cpmac-mii；针对fixed-mii-bus，其值为fixed-0）

read：该mii management提供的读方法，借助该接口，可访问挂载至该mii management上的phy-device；

write：该miimanagement提供的写方法，借助该接口，可修改挂载至该mii management上的phy-device；

reset：是对该mii management控制器的复位方法；

phy_map：该数组成员用于指示目前已扫描到的挂载至该控制器下的phy-device；

phy_mask：用于表示忽略该控制器下某一个phy addr对应的phy-device的探测操作。

?

?

?

Struct phy_driver分析

该结构体的定义如下，主要涉及如下几个方面：

1. 定义了该驱动所识别的phy device对应的id；
2. 定义了device_driver类型的变量，主要用于继承linux设备-总线-驱动模型，实现mdio总线-phy-device、phy-driver的绑定、解绑等操作；
3. 定义了probe、remove、suspend、resume等方法（device_driver中也定义了这些方法），而phy_driver也定义这些方法，可以理解为面向对象的多态行为（借助mdio_bus的probe/remove/suspend/resume，最终调用具体phy_driver的方法）；
4. 定义了针对phy_device的操作方法（phy初始化、phy自适应配置、phy自适应状态的获取等接口）

?

?

struct phy_device分析

该数据结构是针对phy设备的抽象。该数据结构主要涉及如下几个方面：

1. 该数据结构可理解为是phy_driver、mii_bus、device的子类，因此可以使用mii_bus的read/write方法，实现对phy的访问，也可以使用phy_driver的方法，实现对phy的配置操作（配置phy的传输模式（10M/100M/1000M等）、自适应、工作模式（半双工/全双工））
2. state表示phy的状态（PHY_DOWN、PHY_UP、PHY_RUNNING、PHY_AN、PHY_FORCING...）
3. phy_id为phy的厂家标识；
4. speed、duplex、pause、link、autoneg等变量表示phy的工作速率、工作模式、链接状态、是否自适应等信息；
5. attached_dev表示该phy所对应的网络设备；

?

?

以上便是这几个数据结构的定义，根据这些数据结构的定义及他们之间的关联，基本上可理解

mdio子系统驱动模型的内容。

?

二、mdio bus 定义及说明

mdio_bus的定义如下，主要实现内如下：

1. 仅实现了match接口与电源管理相关的接口，而针对设备探测与移除的接口（probe、remove）均没有实现，因此在调用device_register、driver_register进行设备与驱动注册匹配时，则调用device_driver->probe/remove接口实现设备的探测操作，针对phy_driver而言，其phy_driver->driver->probe/remove定义为phy_probe/phy_remove,而这两个接口最终会调用phy_driver->probe/remove接口进行设备的探测与移除操作；
2. 定义了默认设备属性（即所有注册至mdio_bus上的设备，均需要为该设备创建该默认属性文件，这部分内容可参考我之前写的设备驱动模型相关的文章，此处不再细说），该默认属性定义如下，即phy_id的只读属性，可读取该phy_device对应的phyid；

?

?

?

?

三、mdio_bus_class

与spi、mmc子系统类似，mdio子系统针对mii_bus，也创建了对应的类，名称为“mdio_bus”，该类的定义如下：

?

? ? ? 针对mdio_bus_class而言，所有创建的mii_bus，均需要链接至该类，而mii_bus继承自device结构体，而所有的device类型的变量均属于device_kset，而所有的device类型变量与class的关联是通过sym_link实现关联的。如下图即为mii_bus、mii_bus->dev、mdio_bus_class的关联。借助于mii_bus->dev->kobj->kref（引用计数），mii_bus的释放由linux设备-总线-驱动模型的kref进行关联，当mii_bus的引用计数为0时，则触发其relese接口，通过如下图的调用，最终调用mdio_bus_class->dev_release，即mdiobus_release接口，该接口则完成mii_bus类型变量的内存释放操作。

?

?

?

?

? ? ? ? 以上即为本篇文章的内容，主要介绍mii management/mdio子系统的驱动模型及相关的数据结构的介绍；并介绍mdio_bus_type、mdio_bus_class的定义等内容。本篇文章中的介绍也涉及了linux设备-总线-驱动模型、linux sysfs相关内容，若需要对这两部分内容的分析，请参考之前写的文章，强烈建议大家学习下这两部分的内容，只要把这两部分的内容理解了，针对linux系统中总线类的设备驱动模型基本上就可以快速理解。