linux设备驱动程序--bus

linux 中bus驱动解析

总线(bus)是linux发展过程中抽象出来的一种设备模型,为了统一管理所有的设备,内核中每个设备都会被挂载在总线上,这个bus可以是对应硬件的bus(i2c bus、spi bus)、可以是虚拟bus(platform bus)。

简述bus的工作流程

bus将所有挂在上面的具体设备抽象成两部分,driver和device。

driver实现了同类型设备的驱动程序实现,而device则向系统注册具体的设备需要的资源,每当添加一个新的driver(device)到bus中时,都将调用bus的match函数,试图寻找匹配的device(driver)。

总线大概是这样的:

如果匹配成功,就调用probe函数,在probe函数中实现设备的初始化、各种配置以及生成用户空间的文件接口。

举个例子,针对AT24CXX(一种常用的存储设备)这种同系列产品,他们的操作方式都是非常相似的,不同的无非是容量大小。

那么我们就没有必要为AT24C01、AT24C02去分别写一份驱动程序,而是统一为其写一份兼容所有AT24CXX的驱动程序,然后再传入不同的参数以对应具体的型号。

在linux驱动管理模型中的体现就是:驱动程序对应driver、需要的具体型号的硬件资源对应device,将其挂在bus上。

将driver注册到bus上,当用户需要使用AT24C01时,以AT24C01的参数构建一个对应device,注册到bus中,bus的match函数匹配上之后,调用probe函数,即可完成AT24C01的初始化,完成在用户空间的文件接口注册。

以此类推,添加所有的AT24CXX设备都可以以这样的形式实现,只需要构建一份device,而不用为每个设备重写一份驱动,提高了复用性,节省了内存空间。

linux bus结构体

linux将设备挂在总线上,对应设备的注册和匹配流程由总线进行管理,在linux内核中,每一个bus,都由struct bus_type来描述:

struct bus_type {
    const char      *name;
    const char      *dev_name;
    struct device       *dev_root;
    ...
    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);
    struct subsys_private *p;
    ...

};
为了突出重点,省去了一些暂时不需要深入了解的成员,我们来看看其中最主要的几个成员:

name : 该bus的名字,这个名字是这个bus在sysfs文件系统中的体现,对应/sys/bus/$name.
dev_name : 这个dev_name并不对应bus的名称,而是对应bus所包含的struct device的名字,即对应dev_root。
dev_root:bus对应的device结构,每个设备都需要对应一个相应的struct device.
match:bus的device链表和driver链表进行匹配的实际执行回调函数,每当有device或者driver添加到bus中时,调用match函数,为device(driver)寻找匹配的driver(device)。
uevent:bus时间回调函数,当属于这个bus的设备发生添加、删除、修改等行为时,都将出发uvent事件。
probe:当device和driver经由match匹配成功时,将会调用总线的probe函数实现具体driver的初始化。事实上每个driver也会提供相应的probe函数,先调用总线的probe函数,在总线probe函数中调用driver的probe函数。
remove:移除挂载在设备上的driver,bus上的driver部分也会提供remove函数,在执行移除时,先调用driver的remove,然后再调用bus的remove以清除资源。
struct subsys_private *p:见下文

struct subsys_private p
struct subsys_private
p主要实现了对bus中数据的管理:

struct subsys_private {
    struct kset subsys;
    struct kset *devices_kset;

    struct kset *drivers_kset;
    struct klist klist_devices;
    struct klist klist_drivers;
    ...
};

其中struct kset subsys、struct kset devices_kset、struct kset drivers_kset都是在sysfs文件系统中创建对应的目录。

struct klist klist_devices、struct klist klist_drivers是两个主要的数据部分,klist_devices是存储所有注册到bus的device的链表,而klist_drivers是存储所有注册到bus的driver的链表。

bus的注册

了解了bus的结构,那么,bus是怎么注册的呢?

spi bus的注册过程在KERNEL/drivers/spi/spi.c中:

static int __init spi_init(void)
{ 
    ...
    status = bus_register(&spi_bus_type);
    ...
    return 0;
}

postcore_initcall(spi_init);

i2c bus的注册过程在KERNEL/drivers/i2c/i2c-core-base.c中:

static int __init i2c_init(void)
{
    ...
    bus_register(&i2c_bus_type);
    ...
}
postcore_initcall(i2c_init);

而platform bus的注册过程在KERNEL/drivers/base/platform.c中:

int __init platform_bus_init(void)
{
    ...
    bus_register(&platform_bus_type);
    ...
}

i2c和spi为物理总线,这两种总线通过postcore_initcall()将各自的init函数注册到系统中,postcore_initcall的详解可以参考另一篇博客:linux init机制。

而platform作为虚拟总线,platform_bus_init被系统初始化时直接调用,调用流程为:

start_kernel  
-> rest_init();
    -> kernel_thread(kernel_init, NULL, CLONE_FS);
        -> kernel_init()
            -> kernel_init_freeable();
                -> do_basic_setup();
                    -> driver_init();  
                        ->platform_bus_init();

spi_bus_type、i2c_bus_type、platform_bus_type分别为对应的struct bus_type描述结构体。

对应的spi_bus_type、i2c_bus_type、platform_bus_type实现我将分别在spi、i2c、platform具体框架解析中介绍。

bus_register()

可以看到,这三种总线都是由bus_register()接口注册的,那么这个接口到底做了什么呢?

int bus_register(struct bus_type *bus)
{
    int retval;
    struct subsys_private *priv;
    struct lock_class_key *key = &bus->lock_key;

    priv = kzalloc(sizeof(struct subsys_private), GFP_KERNEL);
    if (!priv)
        return -ENOMEM;

    priv->bus = bus;
    bus->p = priv;

    BLOCKING_INIT_NOTIFIER_HEAD(&priv->bus_notifier);

    retval = kobject_set_name(&priv->subsys.kobj, "%s", bus->name);
    if (retval)
        goto out;

    priv->subsys.kobj.kset = bus_kset;
    priv->subsys.kobj.ktype = &bus_ktype;
    priv->drivers_autoprobe = 1;

    retval = kset_register(&priv->subsys);
    if (retval)
        goto out;

    retval = bus_create_file(bus, &bus_attr_uevent);
    if (retval)
        goto bus_uevent_fail;

    priv->devices_kset = kset_create_and_add("devices", NULL,
                        &priv->subsys.kobj);
    if (!priv->devices_kset) {
        retval = -ENOMEM;
        goto bus_devices_fail;
    }

    priv->drivers_kset = kset_create_and_add("drivers", NULL,
                        &priv->subsys.kobj);
    if (!priv->drivers_kset) {
        retval = -ENOMEM;
        goto bus_drivers_fail;
    }

    INIT_LIST_HEAD(&priv->interfaces);
    __mutex_init(&priv->mutex, "subsys mutex", key);
    klist_init(&priv->klist_devices, klist_devices_get, klist_devices_put);
    klist_init(&priv->klist_drivers, NULL, NULL);

    retval = add_probe_files(bus);
    if (retval)
        goto bus_probe_files_fail;

    retval = bus_add_groups(bus, bus->bus_groups);
    if (retval)
        goto bus_groups_fail;

    pr_debug("bus: '%s': registered\n", bus->name);
    return 0;

}

在上面贴出的代码中,可以看出,bus_register()其实也没做什么特别的事,主要是两个:

  • 在sysfs系统中注册各种用户文件接口,将bus的信息和操作接口导出到用户接口。
  • 初始化device和driver链表。

向总线中添加driver/device

既然bus_register只是初始化了相应的资源,在/sys下导出接口文件,那整个bus是如何工作的呢?

以i2c为例,我们来看看这整个过程:

首先使用i2c_new_device接口来添加一个device:

struct i2c_client *i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
{
    struct i2c_client   *client;
    client = kzalloc(sizeof *client, GFP_KERNEL);
    client->adapter = adap;

    client->dev.platform_data = info->platform_data;
    if (info->archdata)
        client->dev.archdata = *info->archdata;
    client->flags = info->flags;
    client->addr = info->addr;

    client->irq = info->irq;
    client->dev.parent = &client->adapter->dev;
    client->dev.bus = &i2c_bus_type;
    client->dev.type = &i2c_client_type;
    client->dev.of_node = info->of_node;
    client->dev.fwnode = info->fwnode;
    ...
    device_register(&client->dev);
    ...
}

申请一个i2c_client并对其赋值,然后以这个为参数调用device_register(&client->dev),将dangqiandevice添加到bus中。

int device_register(struct device *dev)
{
    device_initialize(dev);
    return device_add(dev);
}

int device_add(struct device *dev)
{
    ...
     bus_add_device(dev);
    ...
}
int bus_add_device(struct device *dev){
    ...
    klist_add_tail(&dev->p->knode_bus, &bus->p->klist_devices);
    ...
    bus_probe_device(dev);
    ...
}

在device_register中,调用了device_add,紧接着调用bus_add_device,根据函数名称可以看出是将这个device添加到对应的bus中。

果然,根据bus_add_device()的源代码,可以看到,将当前device链接到其对应bus的devices链表,然后在下面调用bus_probe_device();这个函数的作用就是轮询对应bus的drivers链接,查看新添加的device是否存在匹配的driver。

对应的,i2c_driver_register()将i2c driver部分添加到bus中,再轮询检查bus的devices链表是否有对应的device能匹配上,有兴趣的可以从i2c_driver_register()开始研究源代码。

device和driver的匹配

上文中提到当bus中有新的device和driver添加时,会调用bus的match函数进行匹配,那么到底是怎么匹配的呢?

简单来说,在静态定义的device中,一般会有.name属性,与driver的.id_table属性相匹配。

device部分还有可能从设备树转换而来,就有设备树中相应的.compatible属性和driver的of_match_table.compatible属性相匹配。

事实上对于匹配这一部分,可以直接参考每个bus的match函数实现。

这一章节只是对linux中的总线做一个概念性的说明,在之后的博客中会详细介绍到相应bus的框架,同时也会详解对应的match()函数实现。

敬请期待!

好了,关于linux的bus讨论就到此为止啦,如果朋友们对于这个有什么疑问或者发现有文章中有什么错误,欢迎留言

原创博客,转载请注明出处!

祝各位早日实现项目丛中过,bug不沾身.

转载于:https://www.cnblogs.com/downey-blog/p/10507703.html

你可能感兴趣的:(linux设备驱动程序--bus)