linux核心匯流排驅動模型-驅動篇

如果你瞭解了前面匯流排、裝置模型，分析匯流排裝置驅動模型的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);