LV06-04-linux设备模型-06-注册自定义总线
已经学习完kobject相关的东西了,来注册一个自己的总线?若笔记中有错误或者不合适的地方,欢迎批评指正😃。
点击查看使用工具及版本
PC端开发环境 | Windows | Windows11 |
Ubuntu | Ubuntu20.04.2的64位版本 | |
VMware® Workstation 17 Pro | 17.6.0 build-24238078 | |
终端软件 | MobaXterm(Professional Edition v23.0 Build 5042 (license)) | |
Win32DiskImager | Win32DiskImager v1.0 | |
Linux开发板环境 | Linux开发板 | 正点原子 i.MX6ULL Linux 阿尔法开发板 |
uboot | NXP官方提供的uboot,使用的uboot版本为U-Boot 2019.04 | |
linux内核 | linux-4.19.71(NXP官方提供) |
点击查看本文参考资料
分类 | 网址 | 说明 |
官方网站 | https://www.arm.com/ | ARM官方网站,在这里我们可以找到Cotex-Mx以及ARMVx的一些文档 |
https://www.nxp.com.cn/ | NXP官方网站 | |
https://www.nxpic.org.cn/ | NXP 官方社区 | |
https://u-boot.readthedocs.io/en/latest/ | u-boot官网 | |
https://www.kernel.org/ | linux内核官网 |
点击查看相关文件下载
分类 | 网址 | 说明 |
NXP | https://github.com/nxp-imx | NXP imx开发资源GitHub组织,里边会有u-boot和linux内核的仓库 |
nxp-imx/linux-imx/releases/tag/v4.19.71 | NXP linux内核仓库tags中的v4.19.71 | |
nxp-imx/uboot-imx/releases/tag/rel_imx_4.19.35_1.1.0 | NXP u-boot仓库tags中的rel_imx_4.19.35_1.1.0 | |
I.MX6ULL | i.MX 6ULL Applications Processors for Industrial Products | I.MX6ULL 芯片手册(datasheet,可以在线查看) |
i.MX 6ULL Applications ProcessorReference Manual | I.MX6ULL 参考手册(下载后才能查看,需要登录NXP官网) | |
Source Code | https://elixir.bootlin.com/linux/latest/source | linux kernel源码 |
kernel/git/stable/linux.git - Linux kernel stable tree | linux kernel源码(官网,tag 4.19.71) | |
https://elixir.bootlin.com/u-boot/latest/source | uboot源码 |
在设备模型中,包含总线、设备、驱动和类四个概念。在前面的笔记中,学习了设备模型的基本框架 kobject 和 kset。这一节,我们来注册一个自己的总线。
一、总线
其实下面这些大部分在《LV06-04-linux设备模型-01-设备模型简介.md》这一节中都已经大概了解过了,这里简单回顾一下吧。
1. 总线简介
1.1 总线与平台总线
在设备驱动模型中, 引入总线的概念可以对驱动代码和设备信息进行分离。但是驱动中总线的概念是软件层面的一种抽象,与我们SOC中物理总线的概念并不严格相等:
- 物理总线:芯片与各个功能外设之间传送信息的公共通信干线,其中又包括数据总线、地址总线和控制总线,以此来传输各种通信时序。
- 驱动总线:负责管理设备和驱动。制定设备和驱动的匹配规则,一旦总线上注册了新的设备或者是新的驱动,总线将尝试为它们进行配对。
总线是连接处理器和设备之间的桥梁,总线代表着同类设备需要共同遵守的工作时序,是连接处理器和设备之间的桥梁。我们接触到的设备大部分是依靠总线来进行通信的, 它们之间的物理连接如图所示:
总线驱动则负责实现总线的各种行为,其管理着两个链表,分别是添加到该总线的设备链表以及注册到该总线的驱动链表。当我们向总线添加(移除)一个设备(驱动)时,便会在对应的列表上添加新的节点, 同时对挂载在该总线的驱动以及设备进行匹配,在匹配过程中会忽略掉那些已经有驱动匹配的设备。
一般对于I2C、SPI、USB这些常见类型的物理总线来说,Linux内核会自动创建与之相应的驱动总线,因此I2C设备、SPI设备、 USB设备自然是注册挂载在相应的总线上。但是,实际项目开发中还有很多结构简单的设备,对它们进行控制并不需要特殊的时序。 它们也就没有相应的物理总线,比如led、rtc时钟、蜂鸣器、按键等等,Linux内核将不会为它们创建相应的驱动总线。
为了使这部分设备的驱动开发也能够遵循设备驱动模型,Linux内核引入了一种虚拟的总线——平台总线( platform bus )。 平台总线用于管理、挂载那些没有相应物理总线的设备,这些设备被称为平台设备,对应的设备驱动则被称为平台驱动。 平台设备驱动的核心依然是Linux设备驱动模型,平台设备使用platform_device结构体来进行表示,其继承了设备驱动模型中的device结构体。 而平台驱动使用platform_driver结构体来进行表示,其则是继承了设备驱动模型中的device_driver结构体。
1.2 struct bus_type
在内核中使用结构体 bus_type 来表示总线,它定义在:device.h - include/linux/device.h - struct bus_type
1 | struct bus_type { |
- name :指定总线的名称,当新注册一种总线类型时,会在/sys/bus目录创建一个新的目录,目录名就是该参数的值;
- drv_groups、dev_groups、bus_groups :分别表示驱动、设备以及总线的属性。这些属性可以是内部变量、字符串等等。通常会在对应的/sys目录下在以文件的形式存在,对于驱动而言,在目录
/sys/bus/<bus-name>/driver/<driver-name>
存放了设备的默认属性;设备则在目录/sys/bus/<bus-name>/devices/<driver-name>
中。这些文件一般是可读写的,用户可以通过读写操作来获取和设置这些attribute的值。 - match :当向总线注册一个新的设备或者是新的驱动时,会调用该回调函数。该回调函数主要负责判断是否有注册了的驱动适合新的设备,或者新的驱动能否驱动总线上已注册但没有驱动匹配的设备;
- uevent :总线上的设备发生添加、移除或者其它动作时,就会调用该函数,来通知驱动做出相应的对策。
- probe :当总线将设备以及驱动相匹配之后,执行该回调函数,最终会调用驱动提供的probe函数。
- remove :当设备从总线移除时,调用该回调函数;
- suspend、resume :电源管理的相关函数,当总线进入睡眠模式时,会调用suspend回调函数;而resume回调函数则是在唤醒总线的状态下执行;
- pm :电源管理的结构体,存放了一系列跟总线电源管理有关的函数,与device_driver结构体中的pm_ops有关;
- p :该结构体用于存放特定的私有数据,其成员klist_devices和klist_drivers记录了挂载在该总线的设备和驱动;
其实上面哪些注释里面都有。
1.3 总线的注册与注销
1.3.1 bus_register()
在实际编写linux驱动模块时,Linux内核已经为我们写好了大部分总线驱动,正常情况下我们一般不会去注册一个新的总线, 内核中提供了bus_register函数来注册总线,以及bus_unregister函数来注销总线,它定义在bus.c - drivers/base/bus.c - bus_register
1 | /** |
参数:
- bus: bus_type类型的结构体指针
返回值:
- 成功: 0
- 失败: 负数
1.3.2 bus_unregister()
对应的,我们注销一个总线驱动,可以通过bus_unregister()函数,它定义在:bus.c - drivers/base/bus.c - bus_unregister
1 | /** |
参数:
- bus :bus_type类型的结构体指针
返回值: 无
1.4 总结
当我们成功注册总线时,会在/sys/bus/目录下创建一个新目录,目录名为我们新注册的总线名。bus目录中包含了当前系统中已经注册了的所有总线,例如i2c,spi,platform等。我们看到每个总线目录都拥有两个子目录devices和drivers, 分别记录着挂载在该总线的所有设备以及驱动。
1 | sumu@sumu-virtual-machine:/sys$ tree bus -L 2 |
2. 总线属性文件
2.1 BUS_ATTR()
BUS_ATTR()是一个宏,它定义在device.h - include/linux/device.h - BUS_ATTR:
1 |
struct bus_attribute定义在 device.h - include/linux/device.h - struct bus_attribute
1 | struct bus_attribute { |
2.2 bus_create_file()
bus_create_file()函数,声明在device.h - include/linux/device.h - bus_create_file
1 | extern int __must_check bus_create_file(struct bus_type *, |
参数说明:
- bus:指向总线类型结构体 struct bus_type 的指针,表示要创建属性文件的总线。
- attr:指向属性 struct bus_attribute 的指针,表示要创建的属性文件的属性。
使用bus_create_file()函数,会在
/sys/bus/<bus-name>
下创建对应的文件。
2.3 bus_remove_file()
bus_remove_file()函数,声明在 device.h - include/linux/device.h - bus_remove_file:
1 | extern void bus_remove_file(struct bus_type *, struct bus_attribute *); |
2.4 使用实例
在调用 bus_create_file() 函数之前,需要先定义好属性结构体 struct bus_attribute ,并将其相关字段填充好。有两种方式,一种是直接定义:
1 | struct bus_attribute sbus_attr_name_var = { |
另一种是通过宏来定义:
1 | BUS_ATTR(name_var, S_IRUSR, sbus_attr_name_show, sbus_attr_name_store); // 设置该文件的文件权限为文件拥有者可读,组内成员以及其他成员不可操作 |
show和store函数实现如下:
1 | static ssize_t sbus_attr_name_show(struct bus_type *bus, char *buf) |
3. 总线注册demo
3.1 demo源码
源码可以看这里,这里有两个,一个是只创建总线,另一个还为总线添加了属性文件操作。
05_device_model/11_bus_basic · 苏木/imx6ull-driver-demo - 码云 - 开源中国
05_device_model/12_bus_attr · 苏木/imx6ull-driver-demo - 码云 - 开源中国
点击查看详情
1 |
|
3.2 开发板测试
我们编译完,把对对应的驱动拷贝到开发板中,按以下步骤测试效果。
- (1)一开始的 /sys/bus 目录
- (2)加载模块
加载模块后,会发现,在/sys/bus目录生成了 sbus目录,sbus目录中会有一些默认创建的目录和属性文件,我们自己创建的属性文件也在这里。
- (3)查看的sbus_attr_name值
- (4)修改sbus_attr_name的值
- (5)卸载模块
可以看到,卸载模块后,资源释放,sbus目录被删除,相关的属性文件也都删除了。
二、总线怎么注册的?
那肯定是从 bus_register() 函数开始了。
1. kobject的使用
我们进入到开发板的/sys/bus/sbus 目录:
如上图所示,为什么在 sys/bus 目录下会生成 sbus 目录以及对应的 devices,drivers, drivers_autoprobe,drivers_probe,uevent 目录和属性呢?
在开发板/sys 目录下的目录都对应一个 kobject,所以我们猜测 sbus 目录和 devices,drivers 目录和 kobject 有关系的。而 kobject 一般要嵌入到其他结构体中去使用。如下图所示,kobject 嵌入到 struct device 结构体中:
在 struct device 结构体中包含了 kobject 结构体,而 struct bus_type 结构体又包含了 struct device 结构体。如下图所示:
所以我们猜测这些/sys/bus/下的目录是和 struct device 结构体中的 kobj 有关系。
2. bus_register()
这个函数我们来按行详细分析一下:
1 | /** |
2.1 (1)—— 第 857 行
这一段,分配并初始化一个 struct subsys_private 结构体,用于保存子系统的相关信息。
struct subsys_private 是一个结构体,用于保存驱动核心子系统(bus)的私有信息。每个 子系统都可以有私有数据,这些私有数据就存储在 struct subsys_private 结构体中。
那么什么是子系统呢? 在 Linux 中,子系统是一种机制,用于将特定功能的实现抽象为一个独立的实体。它提供 了一种方便的方式,将相关的代码和数据结构组织在一起,以实现特定的功能。子系统可以被视为一个功能模块,它封装了相关的功能和操作,使得用户和应用程序可以通过统一的接口与 其交互。 在 Linux 中,存在许多常见的子系统,每个子系统都负责实现特定的功能。以下是一些常见的子系统示例。
虚拟文件系统(VFS)子系统:VFS 子系统提供了对不同文件系统的统一访问接口,使得应用程序可以透明地访问各种文件系统(如 ext4、NTFS、FAT 等),而无需关心底层文件系 统的具体实现。
设备驱动子系统:设备驱动子系统管理和控制硬件设备的驱动程序。它提供了与硬件设备 交互的接口,使得应用程序可以通过驱动程序与设备进行通信和控制。
网络子系统:网络子系统负责管理和控制网络相关的功能。它包括网络协议栈、套接字接 口、网络设备驱动程序等,用于实现网络通信和网络协议的处理。
内存管理子系统:内存管理子系统负责管理系统的物理内存和虚拟内存。它包括内存分配、 页面置换、内存映射等功能,用于有效地分配和管理系统的内存资源。
进程管理子系统:进程管理子系统负责管理和控制系统中的进程。它包括进程的创建、调 度、终止等功能,以及进程间通信的机制,如信号、管道、共享内存等。
电源管理子系统:电源管理子系统负责管理和控制系统的电源管理功能。它可以用于控制 电源的开关、电源模式的切换、节能功能的实现等。
文件系统子系统:文件系统子系统负责管理和控制文件系统的创建、格式化、挂载、数据 存取等操作。它支持各种文件系统类型,如 ext4、FAT、NTFS 等。
图形子系统:图形子系统负责管理和控制图形显示功能,包括显示驱动程序、窗口管理、 图形渲染等。它提供了图形界面的支持,使得用户可以通过图形方式与计算机交互。
2.2 (2)—— 第 861 行
将 bus 结构体与 subsys_private 关联起来。
将 priv 结构体中的 bus 成员设置为当前注册的总线。这样做 的目的是将 bus 成员与当前总线建立关联。通过将 bus 成员设置为当前总线,priv 结构体可以 获取并访问与该总线相关的信息和功能。这种关联可以使 priv 结构体在操作当前总线时更加方 便和高效。
将 priv 结构体指针存储在当前注册的总线结构体的成员 p 中, 目的是让当前注册的总线结构体能够快速地找到并访问与之关联的 priv 结构体。通过将 priv 结构体指针存储在总线结构体的成员中,总线可以轻松地获取与之相关的私有数据结构。这种关联使得总线能够直接访问和操作与特定总线相关的数据和功能,而无需通过其他方式来查找或传递指针。
2.3 (10)—— 第 896 行
klist_init() 函数用于初始化两个内核链表(klist),分别是 priv->klist_devices 和 priv->klist_drivers。
这行代码初始化了名为 priv->klist_devices 的内核链表。klist_devices_get 和 klist_devices_put 是两个回调函数,用 于在向链表添加或移除元素时执行相应的操作。通常,这些回调函数用于在链表中的每个 元素被引用或释放时执行额外的操作。例如,当设备被添加到链表时,klist_devices_get() 函数可能会增加设备的引用计数;当设备从链表中移除时,klist_devices_put() 函数可能会减少设备的引用计数。
这行代码初始化了名为 priv->klist_drivers 的内核链表,但与第一个初始化不同,这里没有提供回调函数。因此,这个链表在添加或移除元 素时不会执行额外的操作。这种情况下,链表主要用于存储驱动程序对象,而不需要附加的处理逻辑。
2.4 总结
通过分析 bus_register() 函数,我们对设备模型有了更深层次的了解:
(1)kobject 和 kset 是设备模型的基本框架,它们可以嵌入到其他结构体中以提供设备模型 的功能。kobject 代表设备模型中的一个对象,而 kset 则是一组相关的 kobject 的集合。
(2)属性文件在设备模型中具有重要作用,它们用于在内核空间和用户空间之间进行数据交 换。属性文件可以通过 sysfs 虚拟文件系统在用户空间中表示为文件,用户可以读取或写入这 些文件来与设备模型进行交互。属性文件允许用户访问设备的状态、配置和控制信息,从而实 现了设备模型的管理和配置。
(3)sysfs 虚拟文件系统在设备模型中扮演关键角色,它可以将设备模型的组织层次展现出 来。通过 sysfs,设备模型中的对象、属性和关系可以以目录和文件的形式在用户空间中表示。 这种组织形式使用户能够以层次结构的方式浏览和管理设备模型,从而方便地获取设备的信 息、配置和状态。sysfs 提供了一种统一的接口,使用户能够通过文件系统操作来与设备模型 进行交互,提供了设备模型的可视化和可操作性。