Linux驱动多设备支持：设备树编号与私有数据解耦实战-北京尧图网络

搞过瑞芯微平台的驱动开发的朋友应该都有同感单设备驱动写得再花哨一遇到同一个驱动要管两个一模一样的设备就会开始出各种幺蛾子。比如板子上挂了两个同型号的I2C传感器probe只跑了一次又比如设备节点生成了但open和read操作永远访问的是第一个设备的寄存器再比如两个实例同时跑起来数据互相覆盖得一塌糊涂。这些问题我在RK3568、RK3588的多个项目里反复踩过今天把两个最实用的解决技巧整理出来一个是设备树侧的实例编号设计一个是驱动代码里的私有数据解耦。这篇文章适合正在入门Linux驱动开发、尤其是基于瑞芯微平台做方案验证的工程师也想跟那些已经写了几年驱动但一直靠能跑就行凑合着用的人分享多设备支持这件事前期把结构搭对了后期能少掉一大半头发。1. 为什么单驱动多设备是个真问题1.1 瑞芯微平台上的三类典型多设备场景先看看我们在瑞芯微平台上最常遇到的多设备场景。第一类是同一颗SoC内部集成了多个同类型控制器比如RK3568自带8路UART、多路I2C/SPI/CAN虽然每个控制器都有独立的寄存器基地址和中断号但是驱动代码往往可以共用一套逻辑尤其是CAN、CANFD这类协议栈比较重的控制器一般不会给每个通道各写一份驱动而是用同一个驱动去匹配多个节点。第二类是板级外设重复挂接比如工程上经常在一块板子上放两颗同样型号的温湿度传感器一颗在I2C0上另一颗在I2C2上或者干脆放在同一条I2C总线上用不同地址区分。第三类是带了多个同样功能的扩展芯片比如两片GPIO扩展芯片、两片ADC芯片、两片电机驱动芯片这种在工控和机器人项目里尤其常见一个驱动要能同时管两路甚至更多路硬件。这三类场景本质上都是一个驱动管理多个硬件实例但很多人写驱动的时候心里想着的却是一个驱动对应一个设备的模型代码里充满全局变量设备号写死一个open函数里也不区分到底是哪个实例打开的结果就是产品一量产、用户一接上两路设备问题就全暴露了。1.2 单驱动支持多设备的核心矛盾在哪里要解决多设备支持先要搞清楚矛盾的本质。Linux的设备模型本身就是面向多设备设计的总线负责匹配设备和驱动一个driver可以匹配多个deviceprobe函数按实例调用每一个device结构体都是独立的。真正出问题的往往是两个层面。第一层是设备识别的问题。驱动probe了两次但两次拿到的资源、编号、名称都不区分用户空间看到的只有孤零零的一个设备节点或者设备节点有多个但底层操作串到了一起。第二层是状态隔离的问题。驱动代码里如果用了全局变量来保存设备状态——比如一个全局的结构体指针、一个全局的缓冲区、一个全局的注册标志——那么第二个实例probe的时候就会把第一个实例的现场破坏掉后面所有操作都会访问到错误的地址或错误的数据。这就像一个小卖部只有一个账本两个柜员同时记账最后账目乱成一团谁也不知道谁卖了多少。理解了这两个矛盾之后技巧一和技巧二就有了明确的分工技巧一解决怎么让每个实例都被正确识别的问题技巧二解决怎么让每个实例的状态互不干扰的问题。两个技巧一起用才能让一个驱动在瑞芯微平台上稳定管理多个设备。2. 技巧一设备树里把编号和资源写清楚驱动按实例分工2.1 设备树侧如何组织控制器节点和别名设备树是瑞芯微平台Linux驱动的基石RK3568、RK3588的SDK里SoC级别的控制器节点都定义在rk3568.dtsi之类的文件里板级dts再通过can0 { status okay; }这样的引用来使能。以CAN控制器为例RK3568有3路CANdtsi里通常是这样的// rk3568.dtsi简化 can0: canffc00000 { compatible rockchip,rk3568-can; reg 0x0 0xffc00000 0x0 0x1000; interrupts GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH; clocks cru CLK_CAN0, cru PCLK_CAN0; clock-names baudclk, pclk; status disabled; }; can1: canffc10000 { compatible rockchip,rk3568-can; reg 0x0 0xffc10000 0x0 0x1000; interrupts GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH; clocks cru CLK_CAN1, cru PCLK_CAN1; clock-names baudclk, pclk; status disabled; };如果要在驱动里区分这两路光看compatible是不够的因为两路节点用的是同一个compatible字符串驱动probe的时候会对每个节点各调用一次但你不知道当前调用的到底是哪个节点。这时候两个常用手段就派上用场了。第一个手段是使用aliases在板级dts里给节点起别名并编号aliases { can0 can0; can1 can1; };第二个手段是直接用节点里的reg属性拿到寄存器基地址再从基地址推算实例编号。前者更直接后者更通用。两种方式各有适用场景下面分别说。2.2 驱动侧通过 alias 和 reg 识别当前实例用of_alias_get_id拿实例编号是最推荐的方式因为它把编号这件事显式地放在设备树里驱动代码非常简洁而且和寄存器地址的具体数值解耦static int rkcan_probe(struct platform_device *pdev) { struct device *dev pdev-dev; struct resource *res; void __iomem *base; int irq; int id; id of_alias_get_id(dev-of_node, can); if (id 0) { dev_err(dev, failed to get alias id\n); return -EINVAL; } res platform_get_resource(pdev, IORESOURCE_MEM, 0); base devm_ioremap_resource(dev, res); if (IS_ERR(base)) return PTR_ERR(base); irq platform_get_irq(pdev, 0); if (irq 0) return irq; dev_info(dev, can%d probed, base%px, irq%d\n, id, base, irq); return 0; }这段代码里platform_get_resource和platform_get_irq分别拿到当前节点对应的寄存器和中断资源。资源解析这步要做对不然两个实例可能都解析到同一个地址。需要注意platform_get_resource传给驱动的资源来自设备树节点的reg和interrupts属性如果dtsi里两个节点本来地址就不同这里自然能区分开。如果不想依赖aliases还有一个办法是用of_address_to_resource拿到节点首地址然后算偏移。比如两个设备的寄存器基地址分别是0xffc00000和0xffc10000偏移量固定是0x10000那么id (base_addr - 0xffc00000) / 0x10000也能得到编号。这种方式适合软件和硬件强绑定的场景但灵活性差一些硬件改地址就要改代码所以不如of_alias_get_id推荐。2.3 生成独立的设备节点用户空间才能各找各妈实例编号拿到之后紧接着要做的事就是让用户空间能区分不同设备。Linux字符设备驱动里通常用cdevdevice_create来生成/dev/xxx节点。如果没做任何处理多个实例会挤在同一个次设备号上最终只生成一个节点访问哪个都像在访问第一个设备。正确做法是每个实例独占一个设备号。注册的时候事先分配一组连续的设备号static int major; static struct class *xxx_class; static int __init xxx_init(void) { dev_t devno; major register_chrdev(0, xxx, xxx_fops); // 动态分配主设备号 if (major 0) return major; xxx_class class_create(xxx); if (IS_ERR(xxx_class)) { unregister_chrdev(major, xxx); return PTR_ERR(xxx_class); } // 次设备号0、1分别对应两个实例 devno MKDEV(major, 0); cdev_add(...); // 每个实例单独cdev_add return 0; }在probe里根据拿到的id去创建对应的设备节点cdev_add的次设备号直接使用id值static int xxx_probe(struct platform_device *pdev) { struct xxx_dev *xdev; int id of_alias_get_id(pdev-dev.of_node, xxx); xdev devm_kzalloc(pdev-dev, sizeof(*xdev), GFP_KERNEL); if (!xdev) return -ENOMEM; xdev-id id; dev_set_drvdata(pdev-dev, xdev); // 动态生成 /dev/xxx0、/dev/xxx1 xdev-devno MKDEV(major, id); cdev_init(xdev-cdev, xxx_fops); xdev-cdev.owner THIS_MODULE; cdev_add(xdev-cdev, xdev-devno, 1); xdev-dev device_create(xxx_class, pdev-dev, xdev-devno, xdev, xxx%d, id); if (IS_ERR(xdev-dev)) { cdev_del(xdev-cdev); return PTR_ERR(xdev-dev); } return 0; }这就是技巧一的核心闭环设备树里通过aliases给每个设备节点起好编号驱动probe时用of_alias_get_id拿到编号再靠编号分配不同的设备号最终用户空间得到/dev/xxx0和/dev/xxx1两个互不干扰的节点。这一步做不对后面的状态隔离做得再好用户空间也找不到入口。3. 技巧二用私有数据替代全局变量让多实例并行工作3.1 全局变量为什么会串台我见过不少驱动代码开头写着这样一段static struct xxx_dev *g_dev;然后probe里g_dev devm_kzalloc(...)read里struct xxx_dev *xdev g_dev;就直接拿来用了。单设备的时候看不出问题因为全局只有一个实例。但一旦接上第二个设备第二个实例probe时会把g_dev覆盖成自己那块内存于是第一个设备发送的read请求也会跑到第二个设备的寄存器上去读。两个设备的数据完全串台而且这种串台很难排查因为从代码上看逻辑是对的它确实指向了一个有效的实例只不过永远指向最后probe的那个。这里要理解Linux设备模型的一个基本事实同一个driver的probe对每个设备实例都会调用一次每次调用都应该创建属于这个设备实例的私有数据。驱动在被内核调用的时候并不知道用户是想操作第几个设备它只知道自己正在处理哪个struct device。因此驱动必须把当前是哪个实例的信息跟着调用链传递下去而传递的载体就是驱动的私有数据字段。3.2 私有数据怎么搭dev_set_drvdata 和 file-private_data内核为每个设备预留了一个void *driver_data字段读写接口分别是dev_set_drvdata和dev_get_drvdata。probe的时候不管三七二十一先把当前设备对应的私有结构体指针存进去static int xxx_probe(struct platform_device *pdev) { struct xxx_dev *xdev; xdev devm_kzalloc(pdev-dev, sizeof(*xdev), GFP_KERNEL); if (!xdev) return -ENOMEM; xdev-base devm_ioremap_resource(pdev-dev, ...); xdev-id of_alias_get_id(pdev-dev.of_node, xxx); dev_set_drvdata(pdev-dev, xdev); return 0; }关键的一步来了在open的时候把私有数据从设备的driver_data里取出来绑定到file-private_data上。因为open操作能拿到struct inode而inode里保存着设备号通过设备号可以反推到struct cdev再用container_of拿到我们自己的结构体static int xxx_open(struct inode *inode, struct file *filp) { struct xxx_dev *xdev container_of(inode-i_cdev, struct xxx_dev, cdev); filp-private_data xdev; return 0; }后面的read/write就简单了每次只需要从filp-private_data取回当前实例static ssize_t xxx_read(struct file *filp, char __user *buf, size_t count, loff_t *ppos) { struct xxx_dev *xdev filp-private_data; // 只操作xdev自己的寄存器、自己的缓冲区 ... }这样设计之后两个设备各自有一份struct xxx_dev各自的寄存器映射、各自的缓冲区、各自的状态标志互不干扰。甚至两个设备同时open、同时read也没有问题因为每一次文件操作都只绑定到了打开它的那个设备实例。3.3 字符设备多实例的完整代码骨架把技巧一和技巧二拼起来一个标准的多实例字符设备驱动骨架长这样struct xxx_dev { struct cdev cdev; struct device *dev; void __iomem *base; int id; char name[16]; /* 每个实例自己的数据 */ }; static int xxx_major; static int xxx_probe(struct platform_device *pdev) { struct device *dev pdev-dev; struct xxx_dev *xdev; struct resource *res; // 1. 识别实例 int id of_alias_get_id(dev-of_node, xxx); if (id 0) return -EINVAL; // 2. 分配私有数据 xdev devm_kzalloc(dev, sizeof(*xdev), GFP_KERNEL); if (!xdev) return -ENOMEM; // 3. 解析资源 res platform_get_resource(pdev, IORESOURCE_MEM, 0); xdev-base devm_ioremap_resource(dev, res); if (IS_ERR(xdev-base)) return PTR_ERR(xdev-base); // 4. 保存私有数据和编号 xdev-id id; snprintf(xdev-name, sizeof(xdev-name), xxx%d, id); dev_set_drvdata(dev, xdev); // 5. 创建设备节点 xdev-devno MKDEV(xxx_major, id); cdev_init(xdev-cdev, xxx_fops); xdev-cdev.owner THIS_MODULE; cdev_add(xdev-cdev, xdev-devno, 1); xdev-dev device_create(xxx_class, dev, xdev-devno, xdev, %s, xdev-name); if (IS_ERR(xdev-dev)) { cdev_del(xdev-cdev); return PTR_ERR(xdev-dev); } dev_info(dev, probe %s, base%px\n, xdev-name, xdev-base); return 0; } static int xxx_remove(struct platform_device *pdev) { struct xxx_dev *xdev dev_get_drvdata(pdev-dev); device_destroy(xxx_class, xdev-devno); cdev_del(xdev-cdev); return 0; } static const struct of_device_id xxx_of_match[] { { .compatible vendor,xxx }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, xxx_of_match); static struct platform_driver xxx_driver { .probe xxx_probe, .remove xxx_remove, .driver { .name xxx, .of_match_table xxx_of_match, }, }; module_platform_driver(xxx_driver);这个骨架可以直接套用到瑞芯微平台上的多数控制器和板级外设。核心就两件事probe里给每个设备建一份独立的私有结构体open时通过设备号把对应的结构体绑定到本次文件操作上。3.4 I2C/SPI场景下的另一个思路上面的例子是platform_driver瑞芯微平台上还有大量I2C外设比如挂在I2C总线上的传感器、触摸屏、编解码器。这类设备用i2c_driver区分多实例的方式略有不同但原理一致。i2c_driver的probe回调拿到的是struct i2c_client每个client代表一条I2C总线上一个特定地址的设备所以两颗同型号传感器挂在两条总线上时probe天然会被调两次每次传入不同的client。关键区别在于i2c_client里的addr字段就是设备地址驱动可以用它来区分实例也可以继续沿用私有数据存到dev_set_drvdata(client-dev, xdev)的方式。另外i2c_driver还有一张匹配表常用结构是i2c_device_id里面的driver_data字段可以用于区分同系列但不同型号的芯片static const struct i2c_device_id xxx_id[] { { xxx-a, (kernel_ulong_t)xxx_a_config }, { xxx-b, (kernel_ulong_t)xxx_b_config }, { } }; MODULE_DEVICE_TABLE(i2c, xxx_id); static int xxx_i2c_probe(struct i2c_client *client) { const struct i2c_device_id *id i2c_client_get_device_id(client); const struct xxx_config *cfg (const struct xxx_config *)id-driver_data; struct xxx_dev *xdev; xdev devm_kzalloc(client-dev, sizeof(*xdev), GFP_KERNEL); ... xdev-cfg cfg; // 不同型号的参数不同 ... }这样做的好处是即使两个设备挂在同一条总线上只要地址不同驱动也能通过client-addr区分它们。设备树里的reg属性填的就是I2C地址内核在枚举总线时就会为每个地址创建独立的client驱动只需要相信每个client就是一个设备实例就够了。4. 实操验证在RK3568上把两个设备都带起来4.1 从零验证的完整操作流程技巧说再多不如实际跑一遍。在RK3568的板子上按下面这个流程验证多设备支持基本半小时能出结果。第一步先把设备树改好。找到板级dts文件比如rk3568-evb.dts确保两个控制器节点都使能并且aliases里编号清楚。以CAN为例can0 { status okay; }; can1 { status okay; }; aliases { can0 can0; can1 can1; };第二步编译设备树。在SDK目录下执行make ARCHarm64 CROSS_COMPILEaarch64-linux-gnu- rk3568-evb.dtb然后把新的dtb和内核镜像烧到板子上。如果不想整个烧写也可以单独把dtb放到boot分区很多SDK的update脚本都支持单独更新dtb。第三步编译驱动模块。如果驱动编成了内核模块用SDK里的交叉编译工具链编译make ARCHarm64 CROSS_COMPILEaarch64-linux-gnu- M/path/to/driver modules编译好的.ko文件通过scp或者adb推送到板子上insmod加载insmod xxx.ko dmesg | tail正常的话dmesg里会看到两次probe日志而且日志里带了不同的编号和基地址。比如xxx0 probed, base00000000ffc00000 xxx1 probed, base00000000ffc10000第四步验证设备节点。加载成功后执行ls -l /dev/xxx*应该能看到/dev/xxx0和/dev/xxx1两个节点。然后分别对两个节点做读写测试可以用echo写、用cat或hexdump读确认两个节点操作的是不同的硬件资源。比如两个LED或两个GPIO扩展芯片写节点0点灯A写节点1点灯B现象能对上就说明实例区分成功。4.2 常见问题速查表多设备支持踩坑最多的几个点我整理成一张表方便直接对照排查。现象常见原因排查方法只probe了一次另一个实例没反应节点status为disabledcompatible不匹配I2C地址冲突检查dts里status是否okay对比/proc/device-tree下的compatible字符串看总线枚举日志两个实例都probe了但只生成一个设备节点设备号分配重复cdev_add用同一个次设备号或者device_create命名一样检查probe里是否用实例id作为次设备号检查device_create的name是否有id后缀/dev/xxx0 和 /dev/xxx1 访问的其实是同一个硬件open里没绑定私有数据read/write用全局变量检查open是否从inode-i_cdev取到对应实例查看驱动里是否还在用全局结构体指针两个实例同时工作时数据互相覆盖用了全局缓冲区或全局状态变量把缓冲区、状态标志全部移入每个实例的私有结构体申请中断失败两个实例共用一个中断号dts里interrupts属性配错或中断号没按实例区分用cat /proc/interrupts 查看注册情况检查dts里interrupt-parent和GIC_SPI编号第二行那个只生成一个设备节点的问题特别常见我遇到过好几次原因是没给每个实例分配独立的次设备号。比如MKDEV(major, 0)写死在probe里第二个实例probe时又用了同样的次设备号内核的行为就是覆盖前面那个最终只留下一个节点。解决办法就是像前面代码那样用id作为次设备号。4.3 调试习惯与避坑心得最后分享几个我在瑞芯微平台上调试多设备驱动时沉淀下来的习惯。第一个习惯是probe里多打日志并且日志字符串一定带上实例信息。别小看这个习惯dev_info(pdev-dev, probe done\n)和dev_info(pdev-dev, xxx%d probe done\n, id)在排障时效率差一个量级。因为dev_xxx系列函数本身就会打印设备名但设备名往往是节点路径看不出是第几个实例手动把id加进去dmesg输出一眼就能定位问题。第二个习惯是善用/sys和/proc文件系统。设备树解析成什么样不需要猜直接看ls -l /sys/bus/platform/devices/ cat /proc/device-tree/aliases/can0 cat /proc/device-tree/xxxffc00000/reg这些节点会把设备树里的属性原样展示出来。如果驱动匹配不上第一件事应该是去/proc/device-tree确认节点到底存不存在、compatible写没写对而不是盯着代码反复看。第三个习惯是注意资源释放的顺序。多实例驱动里remove函数必须按probe的逆序释放资源尤其是device_destroy和cdev_del顺序反了可能导致内核崩溃。用devm_系列接口管理内存和ioremap可以省心很多它会自动在设备注销时释放资源但cdev和device_create这类没有devm版本的接口得在remove里手动处理。第四个习惯跟瑞芯微平台的SDK强相关处于调试阶段时不建议把驱动编进内核Image而是编成.ko模块这样改代码不用整个内核重编只要重新编译模块再insmod/rmmod就行。我习惯写一个简单的脚本一键完成交叉编译、推送到板子、insmod、看dmesg四个动作省掉大量重复操作。按我个人的实际操作经验来看先结构、后功能是多设备驱动开发里最值得坚守的原则。我刚开始写这类驱动时也习惯先跑通单设备再说结果后来加第二个实例时改得头疼。现在我的做法是从一开始就在probe里写好实例编号解析设备树aliases先配好所有设备状态全部放进私有结构体即使当前板子上只接了一个设备这些框架代码也提前写好。等真正要接第二个设备的时候只需要在dts里把节点状态改为okay重新编译dtb驱动代码一行都不用动两个实例自然就都跑起来了。这也是这个两个小技巧最大的价值所在——前期多花半小时搭好结构后期省下的排查时间是按天算的。

Linux驱动多设备支持：设备树编号与私有数据解耦实战

相关推荐

串口转WiFi模块改造老仪器：实现数据无线采集与上云实践

TUTK P2P SDK实战：从NAT穿透到音视频远程访问的完整指南

Protobuf代码生成工具实战：从proto文件到多语言代码的完整指南

更多资讯

东莞大朗哪里办电工证？工地太忙根本没时间复习考试

永州电工证好考吗良心建议：别让培训费打水漂

工地太忙根本没时间复习考试？电工证真实考试流程+官方报名入口全解析

东莞大朗哪里办电工证？外省证能转过来吗？考前押题怎么准备

永州电工证好考吗电子证书怎么查

电工证年审不搞懂，找工作都难！南通电工证年审通过率揭秘

今日更新

桐乡去哪考电工证怎么考？全国通用电工证报考全流程详解

低压电工证是必须的嘛电子证书怎么申请更稳妥

特种作业证模板工怎么报名才不会被中介坑

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？