概述
接着上篇文章继续分析mdio子系统,本章主要介绍mdio子系统的驱动模型,当然了介绍mdio子系统的驱动模型,就绕不开linux系统设备-总线-驱动模型,所有的总线类的驱动,基本上都可以理解为继承自linux系统设备-总线-驱动模型。
本篇主要介绍如下几部分的内容:
一、总线-设备-驱动-控制器模型分析
二、总线定义
三、class定义
一、总线-设备-驱动-控制器模型分析
针对驱动模型而言,基本上通过其数据结构的定义及关联,即可窥知一二(结构体一般封装了数据与方法,基本上熟悉数据结构间的关联,也就对其模型有了理解)。下面我们先建立phy_device、phy_driver、mdio_bus、mii_bus、device、device_driver等数据结构之间的关联,介绍该子系统的驱动模型,接着再对具体的数据结构进行分析。
如下图即为这些数据结构间的关联,主要涉及两个方面:
- mdio子系统的驱动模型,主要继承于linux系统的设备-总线-驱动模型,因此通过继承device、device_driver数据结构的定义,完成了mdio_bus_type、device、device_driver的关联,并使用设备-总线-驱动提供的方法完成这些数据结构间的绑定与解绑操作(device_register、driver_register、bus->probe、bus->remove等接口);
- 与之前介绍的mmc、spi、i2c驱动模型类似,mdio驱动模型也定义了phy_device、phy_driver、mii_bus之间的关联,phy_device通过其成员变量,完成了与mii_bus、phy_driver之间的关联:
- phy_device通过其bus指针,可获取其所依附的mii management,即可使用mii_bus提供给的read/write方法;
- 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分析
该结构体的定义如下,主要涉及如下几个方面:
- 定义了该驱动所识别的phy device对应的id;
- 定义了device_driver类型的变量,主要用于继承linux设备-总线-驱动模型,实现mdio总线-phy-device、phy-driver的绑定、解绑等操作;
- 定义了probe、remove、suspend、resume等方法(device_driver中也定义了这些方法),而phy_driver也定义这些方法,可以理解为面向对象的多态行为(借助mdio_bus的probe/remove/suspend/resume,最终调用具体phy_driver的方法);
- 定义了针对phy_device的操作方法(phy初始化、phy自适应配置、phy自适应状态的获取等接口)
struct phy_device分析
该数据结构是针对phy设备的抽象。该数据结构主要涉及如下几个方面:
- 该数据结构可理解为是phy_driver、mii_bus、device的子类,因此可以使用mii_bus的read/write方法,实现对phy的访问,也可以使用phy_driver的方法,实现对phy的配置操作(配置phy的传输模式(10M/100M/1000M等)、自适应、工作模式(半双工/全双工))
- state表示phy的状态(PHY_DOWN、PHY_UP、PHY_RUNNING、PHY_AN、PHY_FORCING...)
- phy_id为phy的厂家标识;
- speed、duplex、pause、link、autoneg等变量表示phy的工作速率、工作模式、链接状态、是否自适应等信息;
- attached_dev表示该phy所对应的网络设备;
以上便是这几个数据结构的定义,根据这些数据结构的定义及他们之间的关联,基本上可理解
mdio子系统驱动模型的内容。
二、mdio bus 定义及说明
mdio_bus的定义如下,主要实现内如下:
- 仅实现了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接口进行设备的探测与移除操作;
- 定义了默认设备属性(即所有注册至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系统中总线类的设备驱动模型基本上就可以快速理解。
最后
以上就是鲤鱼小海豚为你收集整理的Linux Mii management/mdio子系统分析之二 mdio总线-设备-驱动模型分析一、总线-设备-驱动-控制器模型分析二、mdio bus 定义及说明三、mdio_bus_class的全部内容,希望文章能够帮你解决Linux Mii management/mdio子系统分析之二 mdio总线-设备-驱动模型分析一、总线-设备-驱动-控制器模型分析二、mdio bus 定义及说明三、mdio_bus_class所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复