原创 宋宝华 Linux阅码场 7月18日
众所周知,Linux靠设备与驱动之间的match,来完成设备与驱动的bind,从而触发驱动的probe()成员函数被执行。每个bus都有相应的match方法,完成match的总的入口函数是:
1. static inline int driver_match_device(struct device_driver *drv,
2. struct device *dev)
3. {
4. return drv->bus->match ? drv->bus->match(dev, drv) : 1;
5. }
而这个总的入口函数又会调用到各自不同总线的match函数,对于platform bus而言,它的match函数就是platform_match()
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;
17. .
18. /* 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. }
25.
从代码可以看出,platform的driver和device之间的match有很多方法成立,比如设备的name和驱动的name相同:
1. `strcmp(pdev->name, drv->name) == 0`
比如,设备的名字出现在驱动的ID表中:
1. if (pdrv->id_table)
2. return platform_match_id(pdrv->id_table, pdev) != NULL;
比如device tree里面的compatible字段与驱动的dt兼容性字段匹配:
1. if (of_driver_match_device(dev, drv))
2. return 1;
只要符合其中任意一种,driver和device都可以匹配上。
这种自动匹配非常简单,实施起来也非常容易。 但是有时候,这种自动匹配并不一定是我们想要的。比如我们有时候就是希望XXX设备用YYY驱动,而不是用XXX驱动。工程中有手动匹配的需求,最典型的场景是VFIO的场景,想让设备与内核空间原本绑定的驱动解绑,转而采用内核空间的通用VFIO驱动,而VFIO驱动又提供了userspace驾驭设备的能力。
下面我们来从原理和实践上演示这种手动的unbind和bind是怎么进行的。在《Linux设备驱动开发详解》一书中,我们给出了一个简单的globalfifo设备和globalfifo驱动: globalfifo-dev.ko(增加platform_device的模块):
1. static int __init globalfifodev_init(void)
2. {
3. int ret;
4.
5. globalfifo_pdev = platform_device_alloc("globalfifo", -1);
6.
7. ret = platform_device_add(globalfifo_pdev);
8. ...
9. return 0;
10.
11. }
12. module_init(globalfifodev_init);
globalfifo.ko(增加platform_driver的模块):
1 static struct platform_driver globalfifo_driver = {
2 .driver = {
3 . name = "globalfifo",
4 .owner = THIS_MODULE,
5 },
6 .probe = globalfifo_probe,
7 .remove = globalfifo_remove,
8 };
9
10 module_platform_driver(globalfifo_driver);
由于其中的platform_driver和platform_device的name都是“globalfifo”,符合此行的匹配规则:
`1 strcmp(pdev->name, drv->name) == 0`
设备和驱动匹配成功,从sysfs也可以看出:
globalfifo的device和driver各自找到了对方。
现在我们来写一个第三者driver,名字叫做globalxxx,然后我们想把globalfifo device的driver指向globalxxx。因此我们要完成2步:
- unbind:解除globalfifo driver与globalfifo device的绑定
- bind: 进行globalxxx driver与globalfifo device的绑定
第三者globalxxx驱动代码类似: **globalxxx.ko(增加platform_driver的模块)**:
1 static struct platform_driver globalxxx_driver = {
2 .driver = {
3 .name = "globalxxx",
4 .owner = THIS_MODULE,
5 },
6 .probe = globalxxx_probe,
7 .remove = globalxxx_remove,
8 };
9
10 module_platform_driver(globalxxx_driver);
下面我们来完成第一步的unbind,这一步很简单,跑到/sys/bus/platform/drivers/globalfifo目录,把设备globalfifo的名字写进去unbind文件:
当然我们也可以来回折腾着unbind,bind着玩:
这样我们看到一堆的probe(每次设备和驱动bind成功,驱动probe都会执行),remove(每次设备和驱动unbind成功,驱动remove都会执行),最后处于unbind状态。
现在我们来把globalfifo设备bind到globalxxx驱动:
绑定的时候提示错误! 绑定的时候提示错误!! 绑定的时候提示错误!!!
前面我们用globalfifo的driver去bind globalfifo的device的时候,是想怎么绑就怎么绑的,想绑多少次就绑多少次的!为什么换了globalxxx来绑就不行了呢?
爱情不是你想卖想买就能卖 让我挣开 让我明白 放手你的爱
我们来看看这个bind sysfs入口工作的函数bind_store():
1 static ssize_t bind_store(struct device_driver *drv, const char *buf,
2 size_t count)
3 {
4 ...
5 dev = bus_find_device_by_name(bus, NULL, buf);
6 if (dev && dev->driver == NULL && driver_match_device(drv, dev)) {
7 err = device_driver_attach(drv, dev);
8
9 if (err > 0) {
10 /* success */
11 err = count;
12 } else if (err == 0) {
13 /* driver didn't accept device */
14 err = -ENODEV;
15 }
16 }
17 ...
18 }
看起来,如果要强行bind,仍然需要device_driver_attach()成立,否则内核会返回-ENODEV错误:
1 } else if (err == 0) {
2 /* driver didn't accept device */
3 err = -ENODEV;
4 }
根据前文对platform_match()的代码分析,globalxxx driver和globalfifo device确实八竿子都打不着!!没有任何匹配因子。
下面我们来把globalxxx的代码稍微改一下,通过ID表来增加一个匹配因子:
1 static const struct platform_device_id globalxxx_ids[] = {
2 {
3 .name = "globalfifo",
4 },
5 {}
6 };
7 MODULE_DEVICE_TABLE(platform, globalxxx_ids);
8
9 static struct platform_driver globalxxx_driver = {
10 .driver = {
11 .name = "globalxxx",
12 .owner = THIS_MODULE,
13 },
14 .id_table = globalxxx_ids,
15 .probe = globalxxx_probe,
16 .remove = globalxxx_remove,
17 };
18
19 module_platform_driver(globalxxx_driver);
rmmod和insmod globalxxx.ko 然后重新bind:
现在globalfifo device可以在globalxxx和globalfifo这2个driver里面进行自由地bind和unbind!
看到这里,客官们一定觉得这太特么狗血了!不是说可以自由地绑定第三者吗?为嘛还要求这个第三者驱动与这个原先的设备匹配呢?这有嘛意思呢?
别忘了,在platform_match中还有这么一行:
1 if (pdev->driver_override)
2 return !strcmp(pdev->driver_override, drv->name);
**设备完全可以自由地宣布她喜欢的第三者driver,哪怕这个第三者driver和她本身完全没有任何的匹配因子,**操作的入口就是driver_override sysfs文件。 我们完全可以保留globalxxx驱动的原样
1 static struct platform_driver globalxxx_driver = {
2 .driver = {
3 .name = "globalxxx",
4 .owner = THIS_MODULE,
5 },
6 .probe = globalxxx_probe,
7 .remove = globalxxx_remove,
8 };
不去增加任何的id_table,而换做到globalfifo device里面去写driver_override文件,宣布globalxxx driver可以匹配globalfifo device。 这样之后,哪怕globalxxx driver和globalfifo device八竿子打不着,也是可以驱动globalfifo device的。工程里面如果我们想用VFIO的方式来驱动一个设备,就可以这样做:
1 echo vfio-platform > \
2 driver_override
(END)