如果你了解了前面总线、设备模型，分析总线设备驱动模型的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); //驱动卸载时候执行 void (*shutdown) (struct device *dev); int (*suspend) (struct device *dev, pm_message_t state); int (*resume) (struct device *dev); const struct attribute_group **groups; const struct dev_pm_ops *pm; struct driver_private *p; };与device类型相似，其中有一个指向driver_private的指针p，一些与其他的组件相关的联系都被移到这个结构变量中。不展开来看了，看完了关于驱动的一些重要的数据结构，那么开始重要的，如何向内核注册一个drv呢？我们使用driver_register。
int driver_register(struct device_driver *drv) { int ret; struct device_driver *other; BUG_ON(!drv->bus->p); if ((drv->bus->probe && drv->probe) || (drv->bus->remove && drv->remove) || (drv->bus->shutdown && drv->shutdown)) printk(KERN_WARNING "Driver '%s' needs updating - please use " "bus_type methods\n", drv->name); other = driver_find(drv->name, drv->bus); if (other) { printk(KERN_ERR "Error: Driver '%s' is already registered, " "aborting...\n", drv->name); return -EBUSY; } ret = bus_add_driver(drv); if (ret) return ret; ret = driver_add_groups(drv, drv->groups); if (ret) { bus_remove_driver(drv); return ret; } kobject_uevent(&drv->p->kobj, KOBJ_ADD); return ret; }第6-19行，做一些必要的检查，并利用驱动的名字在bus的drv链表中查找是否已存在该驱动。接着，就进入这个函数的重点bus_add_driver，几乎注册所有的工作都是由它来完成。
/** * bus_add_driver - Add a driver to the bus. * @drv: driver. */ int bus_add_driver(struct device_driver *drv) { struct bus_type *bus; struct driver_private *priv; int error = 0; bus = bus_get(drv->bus); //增加总线的bus引用 if (!bus) return -EINVAL; pr_debug("bus: '%s': add driver %s\n", bus->name, drv->name); /*分别driver_private结构体空间，并进行初始化*/ priv = kzalloc(sizeof(*priv), GFP_KERNEL); if (!priv) { error = -ENOMEM; goto out_put_bus; } klist_init(&priv->klist_devices, NULL, NULL); priv->driver = drv; drv->p = priv; priv->kobj.kset = bus->p->drivers_kset; error = kobject_init_and_add(&priv->kobj, &driver_ktype, NULL, "%s", drv->name);//将drv加入到sys中 if (error) goto out_unregister; /*将drv挂入到总线的链表中*/ klist_add_tail(&priv->knode_bus, &bus->p->klist_drivers); /*如果总线可以自动的probe，就会调用该匹配函数*/ if (drv->bus->p->drivers_autoprobe) { error = driver_attach(drv); if (error) goto out_unregister; } module_add_driver(drv->owner, drv); /*在drv目录下创建event属性文件*/ error = driver_create_file(drv, &driver_attr_uevent); if (error) { printk(KERN_ERR "%s: uevent attr (%s) failed\n", __func__, drv->name); } error = driver_add_groups(drv, bus->drv_groups); if (error) { /* How the hell do we get out of this pickle? Give up */ printk(KERN_ERR "%s: driver_create_groups(%s) failed\n", __func__, drv->name); } if (!drv->suppress_bind_attrs) { error = add_bind_files(drv); if (error) { /* Ditto */ printk(KERN_ERR "%s: add_bind_files(%s) failed\n", __func__, drv->name); } } return 0; out_unregister: kobject_put(&priv->kobj); kfree(drv->p); drv->p = NULL; out_put_bus: bus_put(bus); return error; }其实上面的处理过程相对于设备来说，会简单很多，下面主要对当驱动挂接的时候，怎么去匹配进行分析。
int driver_attach(struct device_driver *drv) { return bus_for_each_dev(drv->bus, NULL, drv, __driver_attach); } static int __driver_attach(struct device *dev, void *data) { struct device_driver *drv = 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->parent) /* Needed for USB */ device_lock(dev->parent); device_lock(dev); if (!dev->driver) driver_probe_device(drv, dev); device_unlock(dev); if (dev->parent) device_unlock(dev->parent); return 0; } static inline int driver_match_device(struct device_driver *drv, struct device *dev) { return drv->bus->match ? drv->bus->match(dev, drv) : 1; }最终也是调用总线的match函数来完成设备与驱动的匹配的过程。
以上分析了总线、设备、驱动三种类型，主要是在注册上，其主要是在sysfs中创建目录和属性文件。在设备或者驱动注册到总线上，总线是如何为其找到对应的驱动的过程，下面一个图能很好的说明这一过程。
由图可以清楚的看出，bus的作用是向内核注册一条总线，并将drv一一加入到总线的drv链表，dev一一加入到总线的dev链表。当有设备或驱动注册的时候，在驱动或者设备链表一一取出，调用总线的match函数来完成匹配，匹配成功后调用总线的probe函数。
回顾下driver_register的作用，首先会将drv放入到bus得drv链表，从bus的dev链表取出每一个dev，用总线的match函数来判断能否支持drv
device_register的作用和driver一样，将dev放入到bus得dev链表，从bus的drv链表取出每一个drv，用总线的match函数来判断能否支持dev。
下面来看一个例子:
extern struct bus_type my_bus_type; static int my_probe(struct device *dev) { printk("Driver found device which my driver can handle!\n"); return 0; } static int my_remove(struct device *dev) { printk("Driver found device unpluged!\n"); return 0; } struct device_driver my_driver = { .name = "my_dev", .bus = &my_bus_type, .probe = my_probe, .remove = my_remove, }; /* * Export a simple attribute. */ static ssize_t mydriver_show(struct device_driver *driver, char *buf) { return sprintf(buf, "%s\n", "This is my driver!"); } static DRIVER_ATTR(drv, S_IRUGO, mydriver_show, NULL); static int __init my_driver_init(void) { int ret = 0; /*注册驱动*/ driver_register(&my_driver); /*创建属性文件*/ driver_create_file(&my_driver, &driver_attr_drv); return ret; } static void my_driver_exit(void) { driver_unregister(&my_driver); } module_init(my_driver_init); module_exit(my_driver_exit);