1 设备驱动模型简介

参考以下内容：

Linux 笔记：
https://xuesong.blog.csdn.net/article/details/109522945?spm=1001.2014.3001.5502
正点原子-左盟主驱动开发
网络资料：https://www.cnblogs.com/lizhuming/category/1859545.html

1.1 概念

开发过程中，一般驱动已经由半导体厂家编写好了，而设备驱动一般也由设备器件的厂家编写好了，我们只需要提供设备信息即可，比如 I2C设备的话提供设备连接到了哪个 I2C 接口上，I2C 的速度是多少等等。
相当于将设备信息从设备驱动中剥离开来，驱动使用标准方法去获取到设备信息(比如从设备树中获取到设备信息)，然后根据获取到的设备信息来初始化设备。这样就相当于驱动只负责驱动，设备只负责设备，想办法将两者进行匹配即可。这个就是 Linux中的总线(bus)、驱动(driver)和设备(device)模型，也就是常说的驱动分离。总线就是驱动和设备信息的月老，负责给两者牵线搭桥，如下图所示；

1.2 总线-设备-驱动

总线（bus)：负责管理挂载对应总线的设备以及驱动；
设备(device)：挂载在某个总线的物理设备；
驱动(driver)：与特定设备相关的软件，负责初始化该设备以及提供一些操作该设备的操作方式；
以下只说总线-设备-驱动模式下的操作

总线管理着两个链表：设备链表和驱动链表。
当我们向内核注册一个驱动时，便插入到总线的驱动链表。
当我们向内核注册一个设备时，便插入到总线的设备链表。
在插入的同时，总线会执行一个 bus_type 结构体中的 match 方法对新插入的设备/驱动进行匹配。（例如以名字的方式匹配。方式有很多总，下面再详细分析。）
匹配成功后，会调用驱动 device_driver 结构体中的 probe 方法。（通常在 probe中获取设备资源。具体有开发人员决定。）
在移除设备或驱动时，会调用 device_driver 结构体中的 remove 方法；

2 总线

2.1 介绍：

总线是连接处理器和设备之间的桥梁
代表着同类设备需要共同遵循的工作时序。
总线驱动：

负责实现总线行为，管理两个链表。

struct bus_type {const char              *name;const struct attribute_group **bus_groups;const struct attribute_group **dev_groups;const struct attribute_group **drv_groups;int (*match)(struct device *dev, struct device_driver *drv);int (*uevent)(struct device *dev, struct kobj_uevent_env *env);int (*probe)(struct device *dev);int (*remove)(struct device *dev);int (*suspend)(struct device *dev, pm_message_t state);int (*resume)(struct device *dev);const struct dev_pm_ops *pm;struct subsys_private *p;
};

name：指定总线的名称，当新注册一种总线类型时，会在 /sys/bus 目录创建一个新的目录，目录名就是该参数的值；
bus_groups、dev_groups、drv_groups：分别表示总线、设备、驱动的属性。
通常会在对应的 /sys 目录下在以文件的形式存在，对于驱动而言，在目录 /sys/bus//driver/ 存放了驱动的默认属性；设备则在目录 /sys/bus//devices/ 中。这些文件一般是可读写的，用户可以通过读写操作来获取和设置这些 attribute 的值。
match：当向总线注册一个新的设备或者是新的驱动时，会调用该回调函数。该设备主要负责匹配工作。
uevent：总线上的设备发生添加、移除或者其它动作时，就会调用该函数，来通知驱动做出相应的对策。
probe：当总线将设备以及驱动相匹配之后，执行该回调函数，最终会调用驱动提供的probe 函数。
remove：当设备从总线移除时，调用该回调函数。
suspend、resume：电源管理的相关函数，当总线进入睡眠模式时，会调用suspend回调函数；而resume回调函数则是在唤醒总线的状态下执行。
pm：电源管理的结构体，存放了一系列跟总线电源管理有关的函数，与 device_driver 结构体中的 pm_ops 有关。
p：该结构体用于存放特定的私有数据，其成员 klist_devices 和 klist_drivers 记录了挂载在该总线的设备和驱动。

match 函数，此函数很重要，单词 match 的意思就是“匹配、相配”，因此此函数就是完成设备和驱动之间匹配的，总线就是使用 match 函数来根据注册的设备来查找对应的驱动，或者根据注册的驱动来查找相应的设备，因此每一条总线都必须实现此函数。match 函数有两个参数：dev 和 drv，这两个参数分别为 device 和 device_driver 类型，也就是设备和驱动。

platform 总线是 bus_type 的一个具体实例，定义在文件 drivers/base/platform.c，platform 总
线定义如下

struct bus_type platform_bus_type = {.name = "platform",.dev_groups = platform_dev_groups,.match = platform_match,.uevent = platform_uevent,.pm = &platform_dev_pm_ops,
};

platform_bus_type 就是 platform 平台总线，其中 platform_match 就是匹配函数。我们来看
一下驱动和设备是如何匹配的，platform_match 函数定义在文件 drivers/base/platform.c 中，函
数内容如下所示：

1 static int platform_match(struct device *dev,struct device_driver *drv)
2 {3 struct platform_device *pdev = to_platform_device(dev);
4 struct platform_driver *pdrv = to_platform_driver(drv);
5
6 /*When driver_override is set,only bind to the matching driver*/
7 if (pdev->driver_override)
8 return !strcmp(pdev->driver_override, drv->name);
9
10 /* Attempt an OF style match first */
11 if (of_driver_match_device(dev, drv))
12 return 1;
13
14 /* Then try ACPI style match */
15 if (acpi_driver_match_device(dev, drv))
16 return 1;
/* Then try to match against the id table */
19 if (pdrv->id_table)
20 return platform_match_id(pdrv->id_table, pdev) != NULL;
21
22 /* fall-back to driver name match */
23 return (strcmp(pdev->name, drv->name) == 0);
24 }

驱动和设备的匹配有四种方法：

第一种匹配方式， OF 类型的匹配，也就是设备树采用的匹配方式， of_driver_match_device 函数定义在文件 include/linux/of_device.h 中。device_driver 结构体(表示设备驱动)中有个名为of_match_table的成员变量，此成员变量保存着驱动的compatible匹配表，设备树中的每个设备节点的compatible 属性会和 of_match_table 表中的所有成员比较，查看是否有相同的条目，如果有的话就表示设备和此驱动匹配，设备和驱动匹配成功以后 probe 函数就会执行。
第二种匹配方式，ACPI 匹配方式。第 19~20 行，
第三种匹配方式，id_table 匹配，每个 platform_driver 结构体有一个 id_table成员变量，顾名思义，保存了很多 id 信息。这些 id 信息存放着这个 platformd 驱动所支持的驱动类型。
第四种匹配方式，如果第三种匹配方式的 id_table 不存在的话就直接比较驱动和设备的 name字段，看看是不是相等，如果相等的话就匹配成功。

对于支持设备树的 Linux 版本号，一般设备驱动为了兼容性都支持设备树和无设备树两种匹配方式。也就是第一种匹配方式一般都会存在，第三种和第四种只要存在一种就可以，一般用的最多的还是第四种，也就是直接比较驱动和设备的 name 字段，毕竟这种方式最简单了。

其实，我看这个还是主要因为设备树；

当我们成功注册总线时，会在 /sys/bus/ 目录下创建一个新目录，目录名为我们新注册的总线名。

3 devices

在 /sys/devices 目录记录了系统中所有的设备。
/sys 下的所有设备文件和 /sys/dev 下的所有设备节点都是链接文件，实际上都指向了对应的设备文件。

device 结构体：

struct device
{const char *init_name;struct device           *parent;struct bus_type *bus;struct device_driver *driver;void            *platform_data;void            *driver_data;struct device_node      *of_node;dev_t                   devt;struct class            *class;void (*release)(struct device *dev);const struct attribute_group **groups;  /* optional groups */struct device_private   *p;
};

内核源码路径：内核源码/include/linux/device.h。

init_name：指定该设备的名称，总线匹配时，一般会根据比较名字来进行配对。
parent：表示该设备的父对象，旧版本的设备之间没有任何联系，引入 Linux 设备驱动模块后，设备之间呈现树状结构，便于管理各种设备。
bus：归属与哪个总线。当我们注册设备时，内核便会将该设备注册到对应的总线。
of_node：存放设备树中匹配的设备节点。当内核使能设备树，总线负责将驱动的 of_match_table 以及设备树的
compatible 属性进行比较之后，将匹配的节点保存到该变量。
platform_data：特定设备的私有数据，通常定义在板级文件中。
driver_data：驱动层可以通过 dev_set/get_drvdata 函数来获取该成员变量。
class：指向该设备对应类。
dev：设备号。dev_t 类型。
release：回调函数。当设备被注销时，该函数被调用。
group：指向 struct attribute_group 类型指针指定该设备属性。

driver 结构体：


struct device_driver
{const char              *name;struct bus_type         *bus;struct module           *owner;const char              *mod_name;      /* used for built-in modules */bool suppress_bind_attrs;       /* disables bind/unbind via sysfs */const struct of_device_id       *of_match_table;const struct acpi_device_id     *acpi_match_table;int (*probe) (struct device *dev);int (*remove) (struct device *dev);const struct attribute_group **groups;struct driver_private *p;
};

内核源码路径：内核源码/include/linux/device.h

name：指定驱动名称，总线进行匹配时，利用该成员与设备名进行比较。
bus：归属与哪个总线。内核需要保证在驱动执行之前，对应的总线能够正常工作。
suppress_bind_attrs：布尔量，用于指定是否通过 sysfs 导出 bind 与 unbind文件，bind 与
unbind 文件是驱动用于绑定/解绑关联的设备。
owner：表示该驱动的拥有者，一般设置为 THIS_MODULE。
of_match_table：指定该驱动支持的设备类型。当内核使能设备树时，会利用该成员与设备树中的 compatible 属性进行比较。
remove：当设备从操作系统中拔出或者是系统重启时，会调用该回调函数。
probe：当驱动以及设备匹配后，会执行该回调函数，对设备进行初始化。通常的代码，都是以main函数开始执行的，但是在内核的驱动代码，都是从
probe 函数开始的。
group：指向 struct attribute_group 类型的指针，指定该驱动的属性。

调用关系

platform_device_register
platform_device_adddevice_addbus_add_device // 放入链表bus_probe_device // probe 枚举设备，即找到匹配的(dev, drv)device_initial_probe__device_attachbus_for_each_drv(...,__device_attach_driver,...)__device_attach_driverdriver_match_device(drv, dev) // 是否匹配driver_probe_device // 调用 drv 的 probe
platform_driver_register
__platform_driver_registerdriver_registerbus_add_driver // 放入链表driver_attach(drv)bus_for_each_dev(drv->bus, NULL, drv, __driver_attach);__driver_attachdriver_match_device(drv, dev) // 是否匹配driver_probe_device // 调用 drv 的 probe

设备驱动模型：总线-设备-驱动相关推荐

linux一个spi总线挂多个设备,Linux SPI总线设备驱动模型详解
随着技术不断进步,系统的拓扑结构越来越复杂,对热插拔.跨平台移植性的要求越来越高,早期的内核难以满足这些要求,从linux2.6内核开始,引入了总线设备驱动模型.其实在linux2.4总线的概念就已经 ...
linux用户空间flash驱动,全面掌握Linux驱动框架——字符设备驱动、I2C驱动、总线设备驱动、NAND FLASH驱动...
原标题:全面掌握Linux驱动框架--字符设备驱动.I2C驱动.总线设备驱动.NAND FLASH驱动字符设备驱动哈~ 这几天都在发图,通过这种方式,我们希望能帮大家梳理学过的知识,全局的掌握Li ...
Linux驱动模型之注册驱动
前言驱动的话我们关心几个点: 驱动是怎么添加到总线管理的设备链表上的? 注册驱动后,它是怎么和设备匹配,并最终调用驱动中的probe()函数的? 数据结构首先看下数据结构: struct devi ...
linux设备模型——总线，驱动，设备间的关系
设备模型之kobject,kset及其关系关于linux设备模型kobject,kset,ktype 设备驱动基础0:设备模型之kobject,kset及其关系设备模型之总线,驱动,设备 Linu ...
linux 内核驱动模型,linux设备驱动模型架构分析一
linux设备驱动模型架构分析一发布时间:2018-07-04 15:14, 浏览次数:584 , 标签: linux 概述 LDD3中说:"Linux内核需要一个对系统结构的一般性描述 ...
LINUX设备驱动模型分析之三驱动（DRIVER）接口分析
上一章我们分析了bus-driver-device模型中bus接口部分,本章我们将分析driver接口,在bus-driver-device模型中,driver接口是依附于bus上,而不像device ...
【嵌入式Linux】嵌入式Linux驱动开发基础知识之总线设备驱动模型
文章目录前言 1.驱动编写的三种方法 1.1.传统写法 1.2.总线驱动模型 1.3.设备树驱动模型 2.Linux实现分离:Bus/Dev/Drv模型 2.1.Bus/Dev/Drv模型 2.2. ...
Linux SPI总线设备驱动模型详解
随着技术不断进步,系统的拓扑结构越来越复杂,对热插拔.跨平台移植性的要求越来越高,早期的内核难以满足这些要求,从linux2.6内核开始,引入了总线设备驱动模型.其实在linux2.4总线的概念就已经 ...
设备驱动，字符设备驱动、（总线）设备驱动模型、sysfs文件系统、平台设备驱动
以下内容转载于微信公众号:嵌入式企鹅圈.如有侵权,请告知删除. 学习Linux设备驱动开发的过程中自然会遇到字符设备驱动.平台设备驱动.设备驱动模型和sysfs等相关概念和技术. 对于初学者来说会非常 ...
LINUX I2C设备驱动模型分析之二总线部分分析
上一章我们对I2C模块做了总体框架的分析,本章我们主要分析下I2C模块的总线部分,主要涉及总线初始化.总线相关属性.总线相关接口函数处理等几部分 I2c bus的定义 I2c bus的定义如下,主要 ...

设备驱动模型：总线-设备-驱动