linux驱动编程--设备模型

在前面学习了 kobject和 kset之后，就迫不及待的想开始“研究”设备模型了。经过这几天的学习，感觉受益匪浅。所以就将自己的理解整理了下来

想要完成一个设备的驱动，就要涉及三部分: Bus, device, driver。当然这些“新”节点都是最终继承于kobject。

一.Bus

这里先整理一下BUS，总线负责在设备与驱动间建立连接，包括 I2C, PCI, 串口，platform等。其中platform是虚拟总线。

1.1 结构体

信息结构体是 bus_type.

struct bus_type {

const char *name; //the name of bus

struct bus_attribute *bus_attrs;

//attribute for bus, contain attribute file and some operate function.

// this is a interface between kernel space and user space.

struct device_attribute *dev_attrs; //attribute for device,

struct driver_attribute *drv_attrs; //attribute for deriver

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】;

void 【*shutdown】【struct device *dev】;

int 【*suspend】【struct device *dev, pm_message_t state】;

int 【*suspend_late】【struct device *dev, pm_message_t state】;

int 【*resume_early】【struct device *dev】;

int 【*resume】【struct device *dev】;

struct dev_pm_ops *pm; //power manage

struct bus_type_private *p;

//private data for bus. In fact, it is core of this structure

};

在其中 bus_attrs, dev_attrs 和 drv_attrs记录了该总线的一些属性信息，而最重要的被用来构建该总线的逻辑结构的信息都记录在了bus_type_private中。对应这个总线私有数据结构体的解析如下。

struct bus_type_private {

struct kset subsys;

//there are two points:

//1】.this is a set. It is contain some devices and derivers about this bus.

//2】. it"s parent is @bus_kset, which is the root of all other bus.@bus_kset have many subset, this is just one of them.

struct kset *drivers_kset;

//all drivers about this bus will belong to this set.

struct kset *devices_kset;

//all devices of this bus will belong to this set.

struct klist klist_devices;

struct klist klist_drivers;

//they are two lists , for mount all corresponding nodes.

struct blocking_notifier_head bus_notifier;

unsigned int drivers_autoprobe:1;

//is this bus automaticly run when a new devices arrvied.

//sometime, we can see some attribute files in user space.【for example:@drivers_autoprobe】.

//it is interface that kernel leave user to modify this argument.

struct bus_type *bus;

//just a port for return this bus.

};

其中的klist_devices, klist_drivers 链表会用来挂载该总线的设备与驱动。当需要找东西的时候就会去俩面翻。而上面的两个kset 分别是它们所属的集合。不同的集合对应于不同的操作特性。这是一种很给力的组织结构。就拿这里来说，我们用kobject来组织了一个二维链表【或其他什么数据结构】，每个kobject在这个链表中充当了一个节点。但又想让其中指定的一些kobject节点具有一些属性。kset相当于kobject的属性。它包含了进行事件通知需要的一些数据信息。每当kobject有需要时，就会去找到自己所属的kset,或者上级kobject的kset来用。

1.2 重要函数分析

对于总线的注册需要使用到如下函数，通过分析它的行为对于理解bus_type的逻辑结构是很有帮助。

/**

* bus_register - register a bus with the system.

* @bus: bus.

* Once we have that, we registered the bus with the kobject

* infrastructure, then register the children subsystems it has:

* the devices and drivers that belong to the bus.

int bus_register【struct bus_type *bus】

{

int retval;

struct bus_type_private *priv;

//alloc a private data package for @bus. It is the core of this structure,

//include device list, deriver list and so on.

priv = kzalloc【sizeof【struct bus_type_private】, GFP_KERNEL】;

if 【!priv】

return -ENOMEM;

priv->bus = bus;

bus->p = priv;

BLOCKING_INIT_NOTIFIER_HEAD【&priv->bus_notifier】;

// before we keep on, what we should to know is that this bus is one of members of the great building,

//so it must be inherit form @kobject.

//and @【priv->subsys.kobj】 is it"s kobject.

retval = kobject_set_name【&priv->subsys.kobj, "%s", bus->name】;

if 【retval】

goto out;

priv->subsys.kobj.kset = bus_kset; //1】.@bus_kset is the root of all buses. 2】. this structure is the type of bus.

priv->subsys.kobj.ktype = &bus_ktype; //corresponding operation function for bus

priv->drivers_autoprobe = 1; //automaticly probe when new device arrived.

retval = kset_register【&priv->subsys】;

if 【retval】

goto out;

retval = bus_create_file【bus, &bus_attr_uevent】; //create attribute file for bus,it is a interface between user space and kernel space.

if 【retval】

goto bus_uevent_fail;

//给该总线创建一个设备子集,it is the set of all devices about this bus.

//在文件系统中的表现就是在该总线的目录下多了一个名字叫"devices"的子目录

//还需要提醒的一点就是:设备模型中的层次结构关系都是由kobject对象来指定，所以凡是属于这个设备模型的节点必须要继承kobject.

priv->devices_kset = kset_create_and_add【"devices", NULL,

&priv->subsys.kobj】;

if 【!priv->devices_kset】 {

retval = -ENOMEM;

goto bus_devices_fail;

}

//create a deriver set for this bus

priv->drivers_kset = kset_create_and_add【"drivers", NULL,

&priv->subsys.kobj】;

if 【!priv->drivers_kset】 {

retval = -ENOMEM;

goto bus_drivers_fail;

}

//thoes two list is used to mount some nodes. device-node or deriver-node.

klist_init【&priv->klist_devices, klist_devices_get, klist_devices_put】;

klist_init【&priv->klist_drivers, NULL, NULL】;

//create attribute file for this structure

retval = add_probe_files【bus】;

if 【retval】

goto bus_probe_files_fail;

retval = bus_add_attrs【bus】; //create attribute file for @bus_attr

if 【retval】

goto bus_attrs_fail;

pr_debug【"bus: "%s": registeredn", bus->name】;

return 0;

bus_attrs_fail:

remove_probe_files【bus】;

bus_probe_files_fail:

kset_unregister【bus->p->drivers_kset】;

bus_drivers_fail:

kset_unregister【bus->p->devices_kset】;

bus_devices_fail:

bus_remove_file【bus, &bus_attr_uevent】;

bus_uevent_fail:

kset_unregister【&bus->p->subsys】;

kfree【bus->p】;

out:

bus->p = NULL;

return retval;

}

在函数体中已经对行为进行了较详细的分析。

1.3 device_bind_driver

那么device到底又是怎么和一个driver进行绑定的呢?让它们在需要时能找到彼此

//bind a driver to one device.

int device_bind_driver【struct device *dev】

{

int ret;

ret = driver_sysfs_add【dev】;

if 【!ret】

driver_bound【dev】;

return ret;

}

//这个函数是在设备已经绑定驱动之后使用，

static void driver_bound【struct device *dev】

{

if 【klist_node_attached【&dev->p->knode_driver】】 {

printk【KERN_WARNING "%s: device %s already boundn",

__func__, kobject_name【&dev->kobj】】;

return;

}

pr_debug【"driver: "%s": %s: bound to device "%s"n", dev_name【dev】,

__func__, dev->driver->name】;

if 【dev->bus】

blocking_notifier_call_chain【&dev->bus->p->bus_notifier,

BUS_NOTIFY_BOUND_DRIVER, dev】;

//把设备节点加入驱动的节点链表中

//?既然设备已经能找到自己的驱动了，为什么还需要加入驱动的链表

//?一个驱动可能支持一组设备，对于那些逻辑操作相同的设备,所有驱动有一个设备链表

klist_add_tail【&dev->p->knode_driver, &dev->driver->p->klist_devices】;

}

二. 设备信息

2.1 信息结构体

在总线的其中一端挂载的是设备。其用于记录数据和操作的结构体是device.

struct device {

struct device *parent; //parent device

struct device_private *p; //private data for device, 包含了其拓扑结构信息

struct kobject kobj;

//@device is inherit from @kobject. so it is belong to @devices_kset, which is created by kernel for devices and contain of some operation functions for devices.

//devices_kset

const char *init_name; /* initial name of the device */

struct device_type *type;

struct semaphore sem; /* semaphore to synchronize calls to

* its driver.

struct bus_type *bus; /* type of bus device is on */

struct device_driver *driver; /* which driver has allocated this

device */

void *driver_data; /* data private to the driver */

void *platform_data; /* Platform specific data, device

core doesn"t touch it */

struct dev_pm_info power;

#ifdef CONFIG_NUMA

int numa_node; /* NUMA node this device is close to */

#endif

u64 *dma_mask; /* dma mask 【if dma"able device】 */

u64 coherent_dma_mask;/* Like dma_mask, but for

alloc_coherent mappings as

not all hardware supports

64 bit addresses for consistent

allocations such descriptors. */

struct device_dma_parameters *dma_parms;

struct list_head dma_pools; /* dma pools 【if dma"ble】 */

struct dma_coherent_mem *dma_mem; /* internal for coherent mem

override */

/* arch specific additions */

struct dev_archdata archdata;

dev_t devt; /* dev_t, creates the sysfs "dev" */

spinlock_t devres_lock;

struct list_head devres_head;

struct klist_node knode_class;

struct class *class;

struct attribute_group **groups; /* optional groups */

void 【*release】【struct device *dev】;

};

而这个节点的拓扑结构信息则保存在 device_private 中

struct device_private {

struct klist klist_children;

//klist containing all children of this device

struct klist_node knode_parent;

//node in sibling list

struct klist_node knode_driver;

//node in driver list, @device is mount on the list of driver by this member.

//In linux system, one device have only one driver.

//But it is not same as to driver, one driver may have a lot of devices, if only those device have a same logical operation.

struct klist_node knode_bus;

//apparently, this device is need to mount on the list of bus, too.

struct device *device;

//point to this device

};

2.2 重要函数

设备的注册函数为 device_register【】, 其会建立设备的拓扑关系，并将设备添加到对应总线的拓扑列表中。

int device_register【struct device *dev】

{

device_initialize【dev】;

return device_add【dev】;

}

其中的device_initialize【】在对设备进行初始化。初始化中使用的一个非常重要的变量是devices_kset ，是内核在启动时就建立的专门用来装载设备的集合。与之一起初始化的还有另外两个

void device_initialize【struct device *dev】

{

dev->kobj.kset = devices_kset;

//@devices_kset is created by kernel as the parent of all devices.

kobject_init【&dev->kobj, &device_ktype】;

//@device_ktype 为kobj定义了两个操作函数

INIT_LIST_HEAD【&dev->dma_pools】;

init_MUTEX【&dev->sem】;

spin_lock_init【&dev->devres_lock】;

INIT_LIST_HEAD【&dev->devres_head】;

device_init_wakeup【dev, 0】;

device_pm_init【dev】;

set_dev_node【dev, -1】;

}

那三个重要设备集合的故事是从这开工的

int __init devices_init【void】

{

......

devices_kset = kset_create_and_add【"devices", &device_uevent_ops, NULL】;

dev_kobj = kobject_create_and_add【"dev", NULL】;

sysfs_dev_block_kobj = kobject_create_and_add【"block", dev_kobj】;

sysfs_dev_char_kobj = kobject_create_and_add【"char", dev_kobj】;

......

}

对于设备注册来说核心的操作在device_add【】中完成，其简化版如下

int device_add【struct device *dev】

{

......

kobject_uevent【&dev->kobj, KOBJ_ADD】;

//开始调用事件通知函数

bus_attach_device【dev】;

//attach @device to bus

if 【parent】

klist_add_tail【&dev->p->knode_parent,

&parent->p->klist_children】;

......

}

在这个函数中是bus_attach_device【】完成了最后的操作，将设备挂进总线的链表中，在加粗的部分可以很清楚的看到。

void bus_attach_device【struct device *dev】

{

struct bus_type *bus = dev->bus;

int ret = 0;

if 【bus】 {

if 【bus->p->drivers_autoprobe】

ret = device_attach【dev】;

// if autoprobe = 1,it will bind to driver

WARN_ON【ret < 0】;

//add @device to the devices-list of @bus

if 【ret >= 0】

klist_add_tail【&dev->p->knode_bus,

&bus->p->klist_devices】;

//@device will be add to the list of the bus.

//@knode_bus is a mount point. think about @containerof【】

}

三. 驱动信息

3.1 结构体

记录驱动信息的结构体是device_driver，它就是device, bus, driver这个三角模型中的最后一个了。

struct device_driver {

const char *name;

//it is used to match with the device.

struct bus_type *bus;

//corresponding bus for this driver

struct module *owner;

const char *mod_name; /* used for built-in modules */

int 【*probe】【struct device *dev】;

//this is a probe function, for ensure whether this driver is match with the device.

int 【*remove】【struct device *dev】;

//when this device is removed.

void 【*shutdown】【struct device *dev】;

int 【*suspend】【struct device *dev, pm_message_t state】;

int 【*resume】【struct device *dev】;

struct attribute_group **groups;

struct dev_pm_ops *pm;

struct driver_private *p;

//as the counterpart of @device and @bus, it is also contain of the hierarchy information.

};

当然，和两外两个一样，结构体中也制作了一个专门用来装该驱动节点拓扑信息的结构体，就是driver_private

struct driver_private {

struct kobject kobj;

//of course, @driver is also a @kobject.

//我们使用kobj为了将该节点增加到这个虚拟的层次结构中。

struct klist klist_devices;

//the list of devices. Thanks for device-model, we could use a driver serices for a serice of devices,

// only if they have a similar operation.

struct klist_node knode_bus;

//@driver will be mounted on the list of driver of the bus.

// Usually, there are two list for the bus.

struct module_kobject *mkobj;

struct device_driver *driver;

//point to container.

};

3.2 重要函数

下面来整理一下驱动注册函数 driver_register，因为它包含了这个结构体的最终解释权

int driver_register【struct device_driver *drv】

{

......

//add @driver to the list of drivers of bus.

ret = bus_add_driver【drv】;

......

}

沿着核心部分继续向下找

int bus_add_driver【struct device_driver *drv】

{

......

priv = kzalloc【sizeof【*priv】, GFP_KERNEL】;

......

//该驱动对象属于对应总线的驱动集

priv->kobj.kset = bus->p->drivers_kset;

error = kobject_init_and_add【&priv->kobj, &driver_ktype, NULL,

"%s", drv->name】;

//假如开启了自动探测，则尝试加载设备

if 【drv->bus->p->drivers_autoprobe】 {

error = driver_attach【drv】;

if 【error】

goto out_unregister;

}

//add @driver to the list of drivers of the bus

klist_add_tail【&priv->knode_bus, &bus->p->klist_drivers】;

module_add_driver【drv->owner, drv】;

//create attribute file for driver

error = driver_create_file【drv, &driver_attr_uevent】;

error = driver_add_attrs【bus, drv】;

error = add_bind_files【drv】;

//notify a event, this will notify the user space.

kobject_uevent【&priv->kobj, KOBJ_ADD】;

return 0;

......

}

看到了两件事，一是函数将 driver挂载到了对应总线的链表中，就是这句话 "klist_add_tail【&priv->knode_bus, &bus->p->klist_drivers】 ”，现在我又一次看到了containerof的恶行。自从containerof之后内核经常做一些让我这种新手看着不习惯的链表出来。二是该函数尝试着自动探测对应设备，调用了driver_attach 。这里又出现了一个有趣的东西

/**

* driver_attach - try to bind driver to devices.

* @drv: driver.

* Walk the list of devices that the bus has on it and try to

* match the driver with each one. If driver_probe_device【】

* returns 0 and the @dev->driver is set, we"ve found a

* compatible pair.

int driver_attach【struct device_driver *drv】

{

return bus_for_each_dev【drv->bus, NULL, drv, __driver_attach】;

}

driver_attach函数将会去遍历该总线的设备列表，并对每个遍历到的设备调用__driver_attach ，检查一下是否是自己要找的设备。

static int __driver_attach【struct device *dev, void *data】

{

* Lock device and try to bind to it. We drop the error

* here and always return 0, because we need to keep trying

* to bind to devices and some drivers will return an error

* simply if it didn"t support the device.

* driver_probe_device【】 will spit a warning if there

* is an error.

//假如这个设备不是自己要找的，则马上退出

if 【!driver_match_device【drv, dev】】

return 0;

......

//并且这个设备还没有驱动，如果已经有了也是不行的

if 【!dev->driver】

driver_probe_device【drv, dev】;

......

return 0;

}

接下来就是 driver_probe_device了，这里将会调用探针函数【总线的，或我们的】去检查这个设备是否确实是对应这个驱动的。

int driver_probe_device【struct device_driver *drv, struct device *dev】

{

......

ret = really_probe【dev, drv】;

......

}

static int really_probe【struct device *dev, struct device_driver *drv】

{

......

//假如总线没有定义探针函数，则调用用户填写的探测函数

//只要探针函数返回0值，则表示选中。

if 【dev->bus->probe】 {

ret = dev->bus->probe【dev】;

if 【ret】

goto probe_failed;

} else if 【drv->probe】 {

ret = drv->probe【dev】;

if 【ret】

goto probe_failed;

}

......

//驱动绑定

driver_bound【dev】;

}

从上面已经看到了探针函数的使用过程，再来看最后一个部分。

static void driver_bound【struct device *dev】

{

......

//把设备节点加入驱动的节点链表中

//?既然设备已经能找到自己的驱动了，为什么还需要加入驱动的链表

//?一个驱动可能支持一组设备，对于那些逻辑操作相同的设备,所有驱动有一个设备链表

klist_add_tail【&dev->p->knode_driver, &dev->driver->p->klist_devices】;

......

}

这就是这个驱动的实际运作了。

四. 总结

万老网

linux驱动编程--设备模型

猜你喜欢

最近发表

存储卡如何使用

UBuntu系统安装KVM创建虚拟机遭遇故障

手机qq浏览器503错误怎么解决【手机qq浏览器503错误怎么解决的】

intellij idea程序包不存在解决方法【intellij idea 程序包不存在】

Windows 10 Build 10130怎么快速升级?

i7级别的处理器怎么样

不打开电脑怎么拷走资料

winbox域名登录详情【win10 域名】

iQOO12影像会升级吗

电脑鼠标使用教程