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

这篇具有很好参考价值的文章主要介绍了Linux Mii management/mdio子系统分析之二 mdio总线-设备-驱动模型分析。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。


(转载)原文链接:https://blog.csdn.net/u014044624/article/details/123303139

      接着上篇文章继续分析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的信息。

 

Linux Mii management/mdio子系统分析之二 mdio总线-设备-驱动模型分析,Linux以太网,linux,运维,服务器

以上即是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的探测操作。

 

Linux Mii management/mdio子系统分析之二 mdio总线-设备-驱动模型分析,Linux以太网,linux,运维,服务器

 

 

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自适应状态的获取等接口)

Linux Mii management/mdio子系统分析之二 mdio总线-设备-驱动模型分析,Linux以太网,linux,运维,服务器

 

 

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所对应的网络设备;

 

Linux Mii management/mdio子系统分析之二 mdio总线-设备-驱动模型分析,Linux以太网,linux,运维,服务器

 

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

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;

 

Linux Mii management/mdio子系统分析之二 mdio总线-设备-驱动模型分析,Linux以太网,linux,运维,服务器

 

Linux Mii management/mdio子系统分析之二 mdio总线-设备-驱动模型分析,Linux以太网,linux,运维,服务器

 

 

三、mdio_bus_class

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

Linux Mii management/mdio子系统分析之二 mdio总线-设备-驱动模型分析,Linux以太网,linux,运维,服务器

 

      针对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类型变量的内存释放操作。

Linux Mii management/mdio子系统分析之二 mdio总线-设备-驱动模型分析,Linux以太网,linux,运维,服务器

 

 

 

 

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

      接着上篇文章继续分析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的信息。

 

Linux Mii management/mdio子系统分析之二 mdio总线-设备-驱动模型分析,Linux以太网,linux,运维,服务器

以上即是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的探测操作。

 

Linux Mii management/mdio子系统分析之二 mdio总线-设备-驱动模型分析,Linux以太网,linux,运维,服务器

 

 

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自适应状态的获取等接口)

Linux Mii management/mdio子系统分析之二 mdio总线-设备-驱动模型分析,Linux以太网,linux,运维,服务器

 

 

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所对应的网络设备;

 

Linux Mii management/mdio子系统分析之二 mdio总线-设备-驱动模型分析,Linux以太网,linux,运维,服务器

 

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

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;

 

Linux Mii management/mdio子系统分析之二 mdio总线-设备-驱动模型分析,Linux以太网,linux,运维,服务器

 

Linux Mii management/mdio子系统分析之二 mdio总线-设备-驱动模型分析,Linux以太网,linux,运维,服务器

 

 

三、mdio_bus_class

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

Linux Mii management/mdio子系统分析之二 mdio总线-设备-驱动模型分析,Linux以太网,linux,运维,服务器

 

      针对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类型变量的内存释放操作。

Linux Mii management/mdio子系统分析之二 mdio总线-设备-驱动模型分析,Linux以太网,linux,运维,服务器

 

 

 

 

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

到了这里,关于Linux Mii management/mdio子系统分析之二 mdio总线-设备-驱动模型分析的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【Windows 11】安装 Android子系统 和 Linux子系统

    本文使用电脑系统: 主要就是安装一个名为: 适用于Android的Windows子系统 (WSA)的软件。 首先在电脑的设置里面:时间和语言——语言和地区里面把地区改为美国。 然后到微软商店搜索: Amazon AppStore 。 安装亚马逊应用商店的时候,会首先提示你安装前面说的WSA。如此,我

    2024年02月09日
    浏览(55)
  • OpenHarmony3.1安全子系统-签名系统分析

    应用签名系统主要负责鸿蒙hap应用包的签名完整性校验,以及应用来源识别等功能。 子系统间接口: 应用完整性校验模块给其他模块提供的接口; 完整性校验: 通过验签,保障应用包完整性,防篡改; 应用来源识别: 通过匹配签名证书链与可信源列表,识别应用来源。

    2024年02月05日
    浏览(47)
  • Window10安装linux子系统及子系统安装1Panel面板

    原文地址:Window10安装linux子系统及子系统安装1Panel面板 - Stars-One的杂货小窝 最近看到halo博客发布了2.10.0,终于是新增了个备份功能,于是有了念头想要升级下 但是目前我还是使用halo1.5版本,所以跨版本迁移可能会有问题,官方提议还是先用个测试环境进行测试验证是否有问题 但

    2024年02月08日
    浏览(54)
  • 字符设备驱动之输入子系统分析(二)

    作者: Bright-Ho 联系方式: 836665637@qq.com input 输入子系统框架分析(纯软件方面):   上一节,我们简单的描述的 什么是输入子系统 ; 什么是字符设备 ; 以及其作用 ;重点是我们讲到分析 输入子系统必须结合硬件设备来分析 ;那么这一节,我们主要讲解输入子系统的 软

    2024年02月15日
    浏览(37)
  • 字符设备驱动之输入子系统分析(一)

    作者: Bright-Ho 联系方式: 836665637@qq.com 前言背景描述: 虽然在网上看了很多有关输入子系统的资料和视频,但是真正的,系统的,全面的,来弄清输入子系统,还是要花些时间和精力的!现在我以一个初学者的角度来分析 input 输入子系统; 那么分析 input 输入子系统之前,

    2024年02月15日
    浏览(40)
  • Android13音频子系统分析(一)---整体架构

             目录 一、应用API层 二、Java框架层 三、Native核心层 3.1 AudioFlinger模块 3.2 AudioPolicyService模块 四、HAL层         本文基于AOSP13源码进行分析解读。所以与各个SoC平台厂商提供的运行在真实设备上的源码会有细微差异,但核心原理区别不大。         音频子系

    2024年02月07日
    浏览(51)
  • Linux reset子系统

    文章代码分析基于linux-5.19.13,架构基于aarch64(ARM64)。 复杂IC内部有很多具有独立功能的硬件模块,例如CPU cores、GPU cores、USB控制器、MMC控制器、等等,出于功耗、稳定性等方面的考虑,有些IC在内部为这些硬件模块设计了复位信号(reset signals),软件可通过寄存器(一般

    2024年02月16日
    浏览(42)
  • Linux Input子系统

    按键、鼠标、键盘、触摸屏等都属于输入(input)设备,Linux 内核为此专门做了一个叫做  input 子系统 的 框架 来处理输入事件。本质属于字符设备。 1. input子系统结构如下:  input 子系统分为 input 驱动层、input 核心层、input 事件处理层,最终给用户空间提供可访问的设备节点

    2024年02月10日
    浏览(45)
  • Linux内核(十四)Input 子系统详解 I —— 子系统介绍以及相关结构体解析

    input子系统就是管理输入的子系统 ,和Linux其他子系统一样,都是Linux内核针对某一类设备而创建的框架。 鼠标、键盘、触摸屏等都属于输入设备,Linux将这些设备的共同特性抽象出来,这就形成了input子系统的框架。 Linux内核只需要通过input框架向用户层上报输入事件 (如:

    2024年02月05日
    浏览(47)
  • Android13音频子系统分析(二)---初始化

    目录 一、AudioPolicyService初始化 1.1 AudioPolicyService::onFirstRef()函数 1.2 AudioCommandThread线程 1.3 AudioPolicyManager初始化 1.3.1 解析audio_policy_configuration.xml配置文件 1.3.2 解析audio_policy_engine_configuration.xml配置文件 1.3.3 AudioPolicyManager::onNewAudioModulesAvailableInt()函数 1.3.4 AudioPolicyManager::updateDe

    2024年02月03日
    浏览(46)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包