Linux 驱动开发 | 驱动世界里的宏伟建筑

Linux 的 device model 是一个旨在统一管理所有设备驱动的模型。它犹如一栋规模宏大的建筑:以 kobject、kset、attribute 等作为基本的建筑材料,构造出支撑驱动世界的 bus、device、driver 三大组件,最后通过 sysfs 在各种基础的建筑材料之间建立彼此的互联层次关系,并向外界提供了与建筑内设施进行互动的文件接口。

Linux 驱动开发 | 驱动世界里的宏伟建筑

本文转载自微信公众号「嵌入式Hacker」,作者吴伟东Jack。转载本文请联系嵌入式Hacker众号。

哈喽,我是老吴。

是否每一个上进的人都会觉得自己还可以再努力一点?

事情到了最后,只要没达成目的,总能把失败的原因归为 “没有再努力一点”。

但是,对努力的最大错误认知就是:时间越长,过程越痛苦,代表我越努力。

想一想,是否有更合理的努力方式?

以下是正文:

  • 一、什么是 device model?
  • 二、device model 的 3 个核心概念
  • 三、bus、device、driver 是如何关联的?
  • 四、bus、device、driver 最简单示例
  • 五、小结
  • 六、相关参考

一、什么是 device model?

Linux 的 device model 是一个旨在统一管理所有设备驱动的模型。

它犹如一栋规模宏大的建筑:

以 kobject、kset、attribute 等作为基本的建筑材料,

构造出支撑驱动世界的 bus、device、driver 三大组件,

最后通过 sysfs 在各种基础的建筑材料之间建立彼此的互联层次关系,并向外界提供了与建筑内设施进行互动的文件接口。

Linux 驱动开发 | 驱动世界里的宏伟建筑

device model 有什么作用?

可以将 device 的硬件描述 和 driver 进行分离,提升 driver 的代码复用率;

可以对 device 进行分类;

可以遍历 device 和 driver;

可以更好地呈现设备的拓扑关系;

可以通过 sysfs 访问设备;

可以让设备支持热插拔;

为了控制篇幅,本文将重点放在与驱动工程师关系最紧密的 bus、device、driver 3 个 组件。

二、device model 的 3 个核心概念

device model 里有 3 个核心的概念:

  • bus
  • device
  • driver

什么是 bus?

bus 代表一种总线,例如 I2C、SPI、Usb 等。

bus 是 Linux 设备驱动模型这种建筑的核心框架,系统中的设备和驱动都依附在其周围。

启动系统后,可以通过 /sys/bus 可以查看系统里当前有哪些总线。

bus 由 struct bus_type 来描述:

  1. struct bus_type {
  2.  const char *name;
  3.  const char *dev_name;
  4.  struct device *dev_root;
  5.  const struct attribute_group **bus_groups;
  6.  const struct attribute_group **dev_groups;
  7.  const struct attribute_group **drv_groups;
  8.  int (*match)(struct device *dev, struct device_driver *drv);
  9.  int (*uevent)(struct device *dev, struct kobj_uevent_env *env);
  10.  int (*probe)(struct device *dev);
  11.  int (*remove)(struct device *dev);
  12.  void (*shutdown)(struct device *dev);
  13.  …
  14.  struct subsys_private *p;
  15.  struct lock_class_key lock_key;
  16. };

不需要一下子了解各个成员的作用,用到的时候再说明。

重点关注成员:

  • int (*match)(struct device *dev, struct device_driver *drv),用于判断挂在该 bus 上的设备和驱动是否匹配的回调函数;
  • int (*probe)(struct device *dev),如果 bus 具有探测设备的能力,则会提供该回调函数;
  • struct subsys_private *p,用于管理 bus 上的设备和驱动的数据结构;

注册 bus 的 api:

  1. int bus_register(struct bus_type *bus);

什么是 device ?

device 代表了某个设备。

由 struct device 来描述:

  1. struct device {
  2.  struct device *parent;
  3.  struct device_private *p;
  4.  struct kobject kobj;
  5.  const char *init_name;
  6.  const struct device_type *type;
  7.  struct mutex mutex;
  8.  struct bus_type *bus;
  9.  struct device_driver *driver;
  10.  void *platform_data;
  11.  void *driver_data;
  12.     …
  13. }

重点关注成员:

  • struct kobject kobj,内核对象;
  • struct bus_type *bus,设备所在的总线;
  • struct device_driver *driver,和设备绑定在一起的驱动,如果还没绑定,则为 NULL;

注册 device 的 api:

  1. int device_register(struct device *dev)

什么是 driver?

driver 代表了设备驱动。

由 struct device_driver 来描述:

  1. struct device_driver {
  2.  const char *name;
  3.  struct bus_type *bus;
  4.  struct module *owner;
  5.  const char *mod_name; /* used for built-in modules */
  6.  bool suppress_bind_attrs; /* disables bind/unbind via sysfs */
  7.  enum probe_type probe_type;
  8.  const struct of_device_id *of_match_table;
  9.  const struct acpi_device_id *acpi_match_table;
  10.  int (*probe) (struct device *dev);
  11.  int (*remove) (struct device *dev);
  12.  void (*shutdown) (struct device *dev);
  13.  int (*suspend) (struct device *dev, pm_message_t state);
  14.  int (*resume) (struct device *dev);
  15.  const struct attribute_group **groups;
  16.  const struct dev_pm_ops *pm;
  17.  struct driver_private *p;
  18. };

重点关注成员:

  • struct bus_type *bus;
  • int (*probe) (struct device *dev);

值得一提的是,总线控制器也是一种设备。

例如 I2C 总线控制器这个设备,对应的驱动为 I2C controller driver。

而挂在 I2C 总线上的设备,对应的驱动为 I2C device driver。

注册 driver 的 api:

  1. int driver_register(struct device_driver *drv);

三、bus、device、driver 是如何关联的?

device model 最核心的工作就是维护这三类抽象的实例,以及建立它们之间的关联关系。

bus 如何管理 device 和 driver ?

在 struct bus_type 中有一个 struct subsys_private *p 指针,它负责管理挂在 bus 上的所有设备和驱动,其定义如下:

  1. struct subsys_private {
  2.  struct kset subsys;
  3.  struct kset *devices_kset;
  4.  struct list_head interfaces;
  5.  struct mutex mutex;
  6.  struct kset *drivers_kset;
  7.  struct klist klist_devices;
  8.  struct klist klist_drivers;
  9.  struct blocking_notifier_head bus_notifier;
  10.  unsigned int drivers_autoprobe:1;
  11.  struct bus_type *bus;
  12.  struct kset glue_dirs;
  13.  struct class *class;
  14. };

Linux 驱动开发 | 驱动世界里的宏伟建筑

两个 klist 成员以链表的形式将该总线上所有的驱动与设备链接到一起。

struct kset *drivers_kset 和 struct kset *devices_kset 是在向系统注册当前新总线时动态生成的容纳该总线上所有驱动与设备的 kset。

在内核里,用 kobject 来表示一个对象,kset 则是 kobject set 的缩写,即内核对象集合。

内核用 kobject 和 kset 等数据结构作为原材料,以实现面向对象的方式构建了 device model 的框架。

最后,device 和 device_driver 的 bus 成员也会指向总线:

Linux 驱动开发 | 驱动世界里的宏伟建筑

device 和 driver 的绑定

无论是通过 device_register() 注册一个 device 到 bus 上,

还是通过 driver_register() 注册一个 device_driver 到 bus 上,

都会导致 bus 尝试执行 device 和 driver 的绑定行为。

1. device_register() 触发的绑定

注册 device 时:

  1. int device_register(struct device *dev);
  2.  device_add(dev);
  3.   bus_probe_device(dev);
  4.    __device_attach(dev, true);

__device_attach(dev, true) 会为 device 遍历 bus 上的所有 driver:

  1. bus_for_each_drv(dev->bus, NULL, &data, __device_attach_driver);
  2.  driver_match_device(drv, dev);
  3.   drv->bus->match ? drv->bus->match(dev, drv) : 1;
  4.  driver_probe_device(drv, dev);

driver_match_device() 通过 bus 里的 match 函数来判断是否 device 和 driver 是否匹配,

是否 match 的判断标准一般是通过 of_match_table 或者是 id_table 作为衡量的标准,

以 i2c bus 的 match 函数为例:

  1. static int i2c_device_match(struct device *dev, struct device_driver *drv)
  2. {
  3.  struct i2c_client *client = i2c_verify_client(dev);
  4.  struct i2c_driver *driver;
  5.  /* Attempt an OF style match */
  6.  if (i2c_of_match_device(drv->of_match_table, client))
  7.   return 1;
  8.  /* Then ACPI style match */
  9.  if (acpi_driver_match_device(dev, drv))
  10.   return 1;
  11.  driver = to_i2c_driver(drv);
  12.  /* Finally an I2C match */
  13.  if (i2c_match_id(driver->id_table, client))
  14.   return 1;
  15.  return 0;
  16. }

一旦 match 成功,就会调用 driver_probe_device() 以触发探测设备的行为:

  1. int driver_probe_device(struct device_driver *drv, struct device *dev);
  2.  really_probe(dev, drv);
  3.   if (dev->bus->probe) {
  4.    ret = dev->bus->probe(dev);
  5.   } else if (drv->probe) {
  6.    ret = drv->probe(dev);
  7.   }

如果 bus 具有探测设备的能力的话,例如 pci bus, 则会使用 bus->probe() 探测设备,

否则,使用 driver->probe() 探测设备,driver 的 probe 操作跟具体的硬件设备挂钩。

2. 由 driver_register() 触发的绑定

  1. int driver_register(struct device_driver *drv);
  2.  bus_add_driver(drv);
  3.   driver_attach(drv);

driver_attach(drv) 会为 driver 遍历 bus 上的所有 device:

  1. int driver_attach(struct device_driver *drv);
  2.  bus_for_each_dev(drv->bus, NULL, drv, __driver_attach);
  3.   __driver_attach();
  4.    driver_match_device(drv, dev);
  5.    driver_probe_device(drv, dev);

和 device_register() 一样,最终都会调用 driver_match_device(drv, dev),

进而通过 bus 里的 match 函数来判断是否 device 和 driver 是否匹配。

同样地,一旦 match 成功,就会调用 driver_probe_device() 以触发探测设备的行为,后续的操作和注册设备时是一模一样的。

3. device 和 drvier 的绑定关系

前面说了绑定是如何被触发的,现在来明确一下绑定的具体操作。

对于能成功匹配的 device 和 driver,两者之间的关系是 N 对 1,即可以有多个 device 和 1 个 driver 绑定在一起。

Linux 驱动开发 | 驱动世界里的宏伟建筑

对于 device:

其 driver 成员指向已绑定的 device_driver。

  1. int driver_probe_device(struct device_driver *drv, struct device *dev)
  2.  really_probe(dev, drv);
  3.   dev->driver = drv;

对于 driver:

在 device_driver 里链表 klist_devices 保存了该 driver 上已绑定的所有 device。

  1. int driver_probe_device(struct device_driver *drv, struct device *dev)
  2.  really_probe(dev, drv);
  3.   driver_bound(dev);
  4.    klist_add_tail(&dev->p->knode_driver, &dev->driver->p->klist_devices);

在 /driver/base/driver.c 中,提供了一些 api,用于遍历处理 driver 上绑定的所有 device:

  • int driver_for_each_device()
  • struct device *driver_find_device()

四、bus、device、driver 最简单示例

下面的例子,

构造了一个名为 “simple_bus” 的 bus 实例。

  1. static int sb_match(struct device *dev, struct device_driver *driver)
  2. {
  3.  return !strncmp(dev_name(dev), driver->name, strlen(driver->name));
  4. }
  5. struct bus_type sb_bus_type = {
  6.  .name = “sb”,
  7.  .match = sb_match,
  8. };
  9. static ssize_t version_show(struct bus_type *bus, char *buf)
  10. {
  11.  return snprintf(buf, PAGE_SIZE, “%sn”, Version);
  12. }
  13. static BUS_ATTR_RO(version);
  14. static void sb_dev_release(struct device *dev)
  15. { }
  16. int register_sb_device(struct sb_device *sbdev)
  17. {
  18.     sbdev->dev.bus = &sb_bus_type;
  19.  sbdev->dev.release = sb_dev_release;
  20.     dev_set_name(&sbdev->dev, sbdev->name);
  21.     return device_register(&sbdev->dev);
  22. }
  23. EXPORT_SYMBOL(register_sb_device);
  24. void unregister_sb_device(struct sb_device *sbdev)
  25. {
  26.  device_unregister(&sbdev->dev);
  27. }
  28. EXPORT_SYMBOL(unregister_sb_device);
  29. static int sb_drv_probe(struct device *dev)
  30. {
  31.  printk(KERN_INFO“sb_drv probe %sn”, dev_name(dev));
  32.  return 0;
  33. }
  34. int register_sb_driver(struct sb_driver *sdrv)
  35. {
  36.  sdrv->driver.bus = &sb_bus_type;
  37.  sdrv->driver.probe = &sb_drv_probe;
  38.  return driver_register(&sdrv->driver);
  39. }
  40. EXPORT_SYMBOL(register_sb_driver);
  41. void unregister_sb_driver(struct sb_driver *driver)
  42. {
  43.  driver_unregister(&driver->driver);
  44. }
  45. EXPORT_SYMBOL(unregister_sb_driver);
  46. static int __init sb_bus_init(void)
  47. {
  48.  int ret;
  49.  ret = bus_register(&sb_bus_type);
  50.  if (ret) {
  51.   printk(KERN_ERR “Unable to register sb bus, failure was %dn”,ret);
  52.   return ret;
  53.  }
  54.  if (bus_create_file(&sb_bus_type, &bus_attr_version))
  55.   printk(KERN_ERR “Unable to create version attributen”);
  56.  return 0;
  57. }
  58. static void sb_bus_exit(void)
  59. {
  60.  bus_unregister(&sb_bus_type);
  61. }
  62. module_init(sb_bus_init);
  63. module_exit(sb_bus_exit);

xxx_chip.c:注册4个名为 “chipX” 的 device

  1. struct xxx_chip {
  2.  char devname[20];
  3.  struct sb_device sdev;
  4. };
  5. int chipdev_num = 4;
  6. struct xxx_chip *chipdev;
  7. static void chip_register_dev(struct xxx_chip *dev, int index)
  8. {
  9.  snprintf(dev->devname, sizeof(dev->devname), “chip%d”index);
  10.  dev->sdev.name = dev->devname;
  11.  dev_set_drvdata(&dev->sdev.dev, dev);
  12.  register_sb_device(&dev->sdev);
  13. }
  14. int chip_init(void)
  15. {
  16.     int i;
  17.     chipdev = kmalloc(chipdev_num*sizeof (struct xxx_chip), GFP_KERNEL);
  18.     memset(chipdev, 0, chipdev_num*sizeof (struct xxx_chip));
  19.     for (i = 0; i < chipdev_num; i++) {
  20.   chip_register_dev(chipdev + i, i);
  21.  }
  22.     return 0;
  23. }
  24. void chip_cleanup(void)
  25. {
  26.     int i;
  27.     for (i = 0; i < chipdev_num; i++) {
  28.   unregister_sb_device(&chipdev[i].sdev);
  29.  }
  30.     kfree(chipdev);
  31. }
  32. module_init(chip_init);
  33. module_exit(chip_cleanup);

xxx_chip_drv.c:注册1个名为 “chip” 的 driver

  1. static struct sb_driver sculld_driver = {
  2.  .driver = {
  3.   .name = “chip”,
  4.  },
  5. };
  6. int xxx_chipdrv_init(void)
  7. {
  8.     return register_sb_driver(&sculld_driver);
  9. }
  10. void xxx_chipdrv_cleanup(void)
  11. {
  12.     unregister_sb_driver(&sculld_driver);
  13. }
  14. module_init(xxx_chipdrv_init);
  15. module_exit(xxx_chipdrv_cleanup);

运行效果:

  1. root@buildroot:~# insmod simple_bus.ko
  2. root@buildroot:~# tree /sys/bus/sb
  3. /sys/bus/sb
  4. ├── devices
  5. ├── drivers
  6. ├── drivers_autoprobe
  7. ├── drivers_probe
  8. ├── uevent
  9. └── version
  10. root@buildroot:~# insmod xxx_chip.ko
  11. root@buildroot:~# tree /sys/bus/sb
  12. /sys/bus/sb
  13. ├── devices
  14. │   ├── chip0 -> ../../../devices/chip0
  15. │   ├── chip1 -> ../../../devices/chip1
  16. │   ├── chip2 -> ../../../devices/chip2
  17. │   └── chip3 -> ../../../devices/chip3
  18. ├── drivers
  19. ├── drivers_autoprobe
  20. ├── drivers_probe
  21. ├── uevent
  22. └── version
  23. root@buildroot:~# insmod xxx_chip_drv.ko
  24. sb_drv probe chip0
  25. sb_drv probe chip1
  26. sb_drv probe chip2
  27. sb_drv probe chip3
  28. root@buildroot:~# tree /sys/bus/sb
  29. /sys/bus/sb
  30. ├── devices
  31. │   ├── chip0 -> ../../../devices/chip0
  32. │   ├── chip1 -> ../../../devices/chip1
  33. │   ├── chip2 -> ../../../devices/chip2
  34. │   └── chip3 -> ../../../devices/chip3
  35. ├── drivers
  36. │   └── chip
  37. │       ├── bind
  38. │       ├── chip0 -> ../../../../devices/chip0
  39. │       ├── chip1 -> ../../../../devices/chip1
  40. │       ├── chip2 -> ../../../../devices/chip2
  41. │       ├── chip3 -> ../../../../devices/chip3
  42. │       ├── uevent
  43. │       └── unbind
  44. ├── drivers_autoprobe
  45. ├── drivers_probe
  46. ├── uevent
  47. └── version

通过打印信息可知,device 和 driver 经由 bus 判断是否 match 之后,执行了 driver 的 probe() 函数,符合我们前面的分析。

五、小结

Linux 的 device model 是个非常复杂的系统。

从一个比较高的层次来看,主要由总线、设备和驱动构成。

内核为了实现这些组件间的相关关系,定义了 kobject 和 kset 这样的基础底层数据结构,然后通过 sysfs 文件系统向用户空间展示发生在内核空间中的各组件间的互联层次关系,并以文件系统接口的方式为用户空间程序提供了访问内核对象属性信息的简易方法。

为了控制篇幅,本文并没有涉及到 kojbect 和 sysfs。

如果你感兴趣的话,去挖掘一下以下内容:

  • device model 的底层数据结构 kojbect、kset 是如何工作的?
  • 内核是如何使用 device model 去构建 i2c、spi、usb 等驱动框架?
  • device model 和 sysfs 是如何协同工作的?
  • sysfs 里如何创建属性文件以访问设备驱动?
  • sysfs 里的 class 有什么作用?

六、相关参考

《Linux 设备驱动》

  • 第 14 章 Linux 设备模型

《深入 Linux 设备驱动程序内核机制》

  • 第 9 章 Linux 设备驱动模型

《Linux设备驱动开发详解》

  • 第 5 章 Linux文件系统与设备文件
  • 第 12 章 Linux设备驱动的软件架构思想

Linux/Documentation/driver-model

  • bus.txt
  • class.txt
  • device.txt
  • driver.txt
  • overview.txt

本站原创文章,作者:小 编,如若转载,请注明出处:https://www.mzbky.com/3412.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
小 编的头像小 编新注册
上一篇 2021年3月6日 下午4:53
下一篇 2021年3月11日 下午8:12

相关推荐

发表回复

登录后才能评论