1. 瑞芯微平台上最常见的多设备驱动翻车现场
如果你在瑞芯微平台上写过Linux驱动，大概率碰到过这种场景：板子上接了不止一个同型号设备，两个触摸屏、四颗温湿度传感器或者两块同规格Codec，驱动加载之后只有最后注册的那个能工作，前面的设备要么找不到节点，要么一读写就崩。这个问题在RK3568、RV1126项目里我都踩过，而且翻车翻得非常规律。
我在RK3568上调试过一个多路采集板，I2C0和I2C1上各挂一颗同型号温湿度传感器。第一版驱动写得很“朴素”：全局变量保存i2c_client指针，read函数里直接用全局指针发命令。测试结果很迷惑——只有I2C1上的传感器能上报数据，I2C0那颗“好像不工作”，但单独把I2C0的设备挂上去又一切正常。后来打了一串日志才看明白，probe被调用了两次，第二次把全局指针覆盖成了第二颗传感器，第一颗的命令全发到了第二颗头上。
另一个项目更典型：RK3568的商显主板上，触摸屏有A、B两个型号，寄存器布局不同，但功能完全一样。一开始我想写两套驱动，SDK里多两个文件，维护两份差不多的代码，怎么看都别扭。后来意识到这类问题其实都有成熟套路：一个驱动完全可以同时支持多个型号，也可以在多个实例之间井水不犯河水。
把这两个场景放在一起，你会发现“支持多个设备”本质上是两件事：
- 匹配层面：如何让一套驱动代码同时识别多种型号/兼容设备，并根据型号适配不同参数；
- 实例层面：当一个驱动被多次probe时，如何保证每个设备实例都有自己独立的状态、节点和生命周期，互不干扰。
| 问题维度 | 要解决的核心 | 对应手段 |
|---|---|---|
| 匹配多个型号 | 不同compatible怎么对到不同配置 | of_device_id + data字段 |
| 管理多个实例 | 同一驱动多次probe后状态不串 | 每实例私有结构体 + 动态设备节点 |
这两件事都有通用答案，下面分开讲。
1.1 现象：第二个设备一注册，第一个设备就“瞎了”
这不是驱动没配对的问题，而是驱动状态被覆盖的问题。内核的platform_bus或i2c子系统在扫描到一个设备节点时，就会调用一次驱动probe。你在设备树里写了几个节点，probe就会被调用几次。如果驱动内部只有一个全局数据结构，那每次probe都会把上一次写入的状态冲掉，最终所有IO操作全部落在最后注册的实例上。更隐蔽的是，这种覆盖不会报错，日志看起来一切都正常，只有当你同时操作两个设备时才会发现数据串了。
1.2 问题拆解：支持多个设备到底是哪两件事
在进入具体代码之前，先把思路理清。一个驱动要支持多个设备，必须满足两个约束：一是能“认”多种硬件型号，这是of_match_table等匹配机制的事；二是能“管”多个同时存在的实例，这是实例化私有数据和设备节点的事。两个约束互相独立，可以叠加使用。下面第2节讲匹配，第3节讲实例，第4节给瑞芯微平台上的落地验证清单。
2. 第一个技巧：一套驱动匹配多个型号，核心在 of_device_id 的 data 字段
2.1 设备树匹配机制：compatible 不是随便写的
Linux平台驱动在设备树体系中，是靠driver.driver.of_match_table里的of_device_id数组和设备树节点的compatible属性完成绑定的。当内核遍历设备树创建platform_device（或I2C设备）时，总线层会拿节点的compatible字符串去匹配驱动的of_device_id表，匹配成功就调用probe。
这里最大的一个误解是：很多人以为compatible只是“驱动里写一个字符串，设备树里相同就行”。实际上它包含两层含义。第一层是身份，厂商前缀加型号，例如"rockchip,rk3568-i2c"里的rockchip是厂商，rk3568-i2c是模块型号；第二层是兼容性，一个节点可以写多个compatible字符串，表示该设备兼容多个标准协议或型号。
举个例子，瑞芯微SDK的设备树里经常能看到类似写法：
&i2c0 { compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c"; };这个节点声明自己同时兼容rk3568和rk3399两代I2C控制器的驱动逻辑。驱动侧如果只写了rockchip,rk3568-i2c，它也能匹配这个节点；如果只写了rockchip,rk3399-i2c，同样能匹配。这就是设备树层面“多兼容”的匹配原则。
新手最容易犯的错是在设备树里写一大堆compatible字符串，驱动侧只有一个compatible，加载后怎么都没反应；或者反过来驱动侧写了一大堆，设备树只写一个，结果匹配优先级不符合预期。实际上匹配逻辑是：只要节点compatible数组里的任意一个字符串和of_match_table里任意一项相等，就算匹配成功。多字符串之间是并行关系，并不是数组里第一个字符串优先级最高。
2.2 用 data 字段携带不同型号的参数表
明确了compatible是入口之后，问题变成：设备匹配上了，驱动怎么知道自己该用哪套参数？
最直接的想法是在probe里用of_device_is_compatible()判断当前设备树节点是不是某个型号，然后分支处理。这种做法能用，但代码一旦扩展就容易变成一坨if-else，而且每加一个型号就要改probe。比较优雅的做法是利用of_device_id的data字段，在匹配表里就把型号和参数结构体绑在一起。
struct mychip_cfg { const char *model; u32 reg_version; u32 max_channels; bool need_soft_reset; }; static const struct mychip_cfg mychip_a_cfg = { .model = "A", .reg_version = 0x10, .max_channels = 4, .need_soft_reset = false, }; static const struct mychip_cfg mychip_b_cfg = { .model = "B", .reg_version = 0x20, .max_channels = 8, .need_soft_reset = true, }; static const struct of_device_id mychip_of_match[] = { { .compatible = "mycorp,mychip-a", .data = &mychip_a_cfg }, { .compatible = "mycorp,mychip-b", .data = &mychip_b_cfg }, { /* sentinel */ }, }; MODULE_DEVICE_TABLE(of, mychip_of_match); static int mychip_probe(struct platform_device *pdev) { const struct mychip_cfg *cfg; cfg = of_device_get_match_data(&pdev->dev); if (!cfg) return -EINVAL; dev_info(&pdev->dev, "probe %s, max_channels=%d\n", cfg->model, cfg->max_channels); /* 后续都用 cfg->xxx 访问型号差异 */ return 0; }of_device_get_match_data()会根据当前设备树的compatible，在of_match_table里找到对应项，并把那一项的data指针返回给你。这样A型号和B型号的差异被封装成了纯数据参数，probe代码里不需要任何型号判断。后面如果再出C型号，只需要加一个mychip_c_cfg和一行匹配表，probe代码一行不用改。
参数结构体建议用const static修饰，它本质上是所有实例共享的只读模板。如果某个实例需要保存运行时的变化状态，请放到后面要讲的“每实例私有数据”里，不要往这个只读模板里塞。两者职责不同，混在一起后面调试会非常痛苦。
这种“匹配表数据”写法在Linux内核驱动里非常常见。瑞芯微的不少SoC内部外设驱动也是这么写的，同一控制器IP在不同型号芯片上有寄存器差异时，经常是多个compatible对应同一套匹配表，data字段指向各自差异配置。
2.3 别忘了 MODULE_DEVICE_TABLE 导出和 id_table 兜底
很多人在调试模块驱动时遇到一个诡异问题：设备树里compatible写得完全正确，驱动也编译进内核了或者insmod了，但probe就是不跑。查到最后，往往发现MODULE_DEVICE_TABLE(of, mychip_of_match);这行没写。
这行的作用是把of_match_table导出到模块的alias信息里。设备树环境下的自动匹配虽然不依赖alias，但模块加载器（udev/mdev/modprobe）靠alias才能建立“设备树节点compatible -> 哪个ko文件”的映射。如果驱动是编译进内核的，少了这行还影响不大；如果打算在调试阶段用模块方式加载，少了这行就会出现设备树明明有节点，但modprobe就是不知道加载哪个模块的情况。
验证方法很简单：
modinfo mychip.ko | grep alias能看到类似alias=of:N...T...C...的输出，说明导出成功。
另外还要提一下platform_device_id表。设备树并不是平台设备唯一的描述方式，在一些非设备树的旧平台或早期验证环境里，平台设备通过name匹配驱动，走的是platform_device_id表：
static const struct platform_device_id mychip_id_table[] = { { "mychip-a", (kernel_ulong_t)&mychip_a_cfg }, { "mychip-b", (kernel_ulong_t)&mychip_b_cfg }, { }, }; MODULE_DEVICE_TABLE(platform, mychip_id_table);新内核的platform_match会优先尝试of_match_table，再尝试platform_device_id表。所以对于一个既可能挂在设备树环境、又可能挂在传统平台环境的驱动，两张表都写上是更稳妥的做法。probe里取配置时做一下区分就行：
static int mychip_probe(struct platform_device *pdev) { const struct mychip_cfg *cfg; const struct platform_device_id *id; if (pdev->dev.of_node) { cfg = of_device_get_match_data(&pdev->dev); } else { id = platform_get_device_id(pdev); cfg = id ? (const struct mychip_cfg *)id->driver_data : NULL; } if (!cfg) return -EINVAL; /* 继续初始化 */ return 0; }这段代码看着多，其实也就几行，换来的是不同平台环境下的兼容性。瑞芯微的SDK虽然以设备树为主，但内核里这种兼容写法并不少见，尤其是那些从老平台沿用下来的驱动。
2.4 这个技巧的边界：什么情况不该硬凑
of_device_id.data解决了“多个型号、一套驱动”的问题，但它不是万能胶。我见过有人把I2C接口的触摸屏和SPI接口的触摸屏塞进同一个驱动，probe里用device_property_read_bool()分出两套完全不同的逻辑，代码比两个驱动加起来还长，最后维护自己都想吐。
我的经验是：两个设备如果在总线类型、寄存器访问方式、中断处理流程上有本质差异，不应该硬凑成一个驱动。它们只是“碰巧同名”，不是“同一个家族”。这种情况下宁可拆成两个驱动，或者做成“核心层+总线适配层”的架构，把所有公共逻辑放核心层（core），把I2C、SPI各自入口放在各自的小文件里。这样反而符合内核里常见的驱动拆分思路。
反过来说，of_device_id.data适合的是：型号之间有共性，只有参数和少量初始化流程不同。比如不同的寄存器版本号、不同的通道数、是否需要额外复位、不同型号对某个特性的开关。这种差异用数据表来表示，probe代码只处理“共性逻辑+查表拿差异”，维护成本最低。
3. 第二个技巧：每个设备实例一份私有数据，彻底告别全局变量
3.1 全局结构体怎么了：一次probe一次覆盖
如果说第2节解决的是“匹配多个型号”，这一节解决的是“同一个型号多个实例”。
假设一个板子上挂了3颗同型号传感器，probe会被调用3次。我最初的错误写法很典型：
static struct my_dev g_dev; /* 错的 */ static int mychip_probe(struct i2c_client *client) { g_dev.client = client; ... return 0; }第二次probe执行完，g_dev.client就指向第二颗设备；第三次执行完，前两颗都彻底消失了。更危险的是，如果第一颗设备被remove，驱动如果没有及时清理，g_dev.client依旧残留，用户态再打开设备时就是访问悬空指针，模块崩溃还是小事，内核态野指针操作可能把整个系统打挂。这类问题在支持多设备的驱动里是最常见的入门坑。
根本原因是把“驱动代码”和“设备实例”混为一谈了。内核的驱动模型从来都是“一份代码，多个设备实例”，probe被调用几次，你的设备状态就应该有几个独立副本。每个副本的生命周期要跟对应struct device绑定，而不是跟模块生命周期绑定。
3.2 实例私有数据的标准姿势
正确做法是在每次probe里分配一份私有结构体，保存这个实例需要的全部运行时状态，然后通过dev_set_drvdata挂到device上。以i2c_driver为例：
struct my_dev { struct device *dev; struct i2c_client *client; struct mutex lock; struct cdev cdev; dev_t devno; }; static int mychip_probe(struct i2c_client *client) { struct my_dev *d; d = devm_kzalloc(&client->dev, sizeof(*d), GFP_KERNEL); if (!d) return -ENOMEM; d->dev = &client->dev; d->client = client; mutex_init(&d->lock); i2c_set_clientdata(client, d); /* 注册字符设备/miscdevice 节点，见 3.3 */ return 0; } static void mychip_remove(struct i2c_client *client) { struct my_dev *d = i2c_get_clientdata(client); /* 先删设备节点/cdev，再清理其他资源 */ }devm_kzalloc是devres机制的一部分，设备移除时会自动释放这块内存。这里有个很重要的经验：能用devm接口就用devm接口，它能在probe中途出错时自动回滚已经申请的资源，省掉一大片goto错误处理代码。不过要注意，devm只接管devm_开头的资源。你自己手动misc_register、device_create、alloc_chrdev_region出来的东西，devm都不会帮你清理，必须在remove里手动做。
如果你写的是platform_driver，和i2c_driver的区别只是入口参数不同。probe参数换成struct platform_device *pdev，保存指针用platform_set_drvdata(pdev, d)；在read/write等函数里取私有数据的路径是platform_get_drvdata。这两组API本质都是dev_set_drvdata，只是包装了不同总线设备类型，方便你少写类型转换。
关于锁的提醒：很多驱动在多实例化之后只改了数据存储，忘了锁也要跟着实例化。如果struct mutex lock被定义成模块级的静态变量，那么两个实例之间的所有操作都会被同一把锁串行化，操作不频繁时你可能感觉不到，一旦两个设备同时做批量读写，性能直接打折。更重要的是，锁的语义也要区分——实例自己的锁保护实例自己的状态，全局锁只用来保护模块级的共享数据。不要把两者混用。
3.3 多个设备节点怎么注册：miscdevice动态minor和字符设备方案
实例状态解决了，用户态还需要能区分访问每个设备的接口。最自然的做法是一个实例一个设备节点。
对于中小型外设驱动，我强烈建议优先用miscdevice。它的主设备号是固定的10，次设备号用动态分配，注册流程非常短：
d->miscdev.minor = MISC_DYNAMIC_MINOR; d->miscdev.name = dev_name(&client->dev); d->miscdev.fops = &mychip_fops; d->miscdev.parent = &client->dev; ret = misc_register(&d->miscdev); if (ret) return ret;dev_name(&client->dev)在I2C总线场景下会得到类似0-0048、0-0049这样的名字，天然不会跟另一个实例重复。miscdevice内部的动态次设备号分配会帮你避免自己管理设备号区间，注册后/dev/0-0048、/dev/0-0049自动出现（udev依devnode规则生成）。
miscdevice唯一的问题是动态次设备号池有限。主设备号10下面的次设备号范围总共就256个，而且不少已经被系统固定占用，所以如果一台设备上同类外设数量可能达到几十甚至上百，misc就不够稳了。这种场景应该用标准字符设备加class的方式：
/* 在模块init里只做一次 */ static dev_t mychip_devno_base; static struct class *mychip_class; alloc_chrdev_region(&mychip_devno_base, 0, MAX_INSTANCES, "mychip"); mychip_class = class_create("mychip"); /* 在每次probe里给实例分配一段次设备号 */ d->devno = MKDEV(MAJOR(mychip_devno_base), minor); cdev_init(&d->cdev, &mychip_fops); d->cdev.owner = THIS_MODULE; cdev_add(&d->cdev, d->devno, 1); device_create(mychip_class, &client->dev, d->devno, d, "mychip%d", index);这个方案可控性更强，设备号从alloc_chrdev_region申请的主设备号下顺序分配，每个实例一个次设备号，节点名可以自己带索引。缺点是代码量多，而且在探测到设备之前必须知道MAX_INSTANCES。
这里有个容易踩的坑：class_create、alloc_chrdev_region这类操作绝对不能放在probe里重复执行。你挂第二个设备时，probe再次进来，如果又class_create("mychip")一次，内核会因为同名class已存在而报错或产生残留。这类“模块级资源”应该放在module_init或驱动入口函数里做一次，probe里只负责创建和当前实例绑定的部分。
3.4 file_operations 里怎么找回当前实例
设备节点有了之后，用户态open进来，file_operations需要知道这次访问的是哪个实例。两类注册方式对应的找回路径略有不同，但核心都离不开container_of。
如果你用的是miscdevice，内核的misc_open会把struct miscdevice *存到filp->private_data，所以open里可以这样：
static int mychip_open(struct inode *inode, struct file *filp) { struct my_dev *d = container_of(filp->private_data, struct my_dev, miscdev); filp->private_data = d; return 0; } static ssize_t mychip_read(struct file *filp, char __user *buf, size_t count, loff_t *pos) { struct my_dev *d = filp->private_data; /* 用 d->client / d->lock 操作当前实例 */ }如果你用的是cdev方式，open里从inode找回cdev，再container_of到包含它的私有结构体：
static int mychip_open(struct inode *inode, struct file *filp) { struct my_dev *d = container_of(inode->i_cdev, struct my_dev, cdev); filp->private_data = d; return 0; }container_of不是黑魔法，它就是根据结构体成员和成员地址反推出结构体起始地址。但它要求你传入的成员类型必须和结构体定义完全一致，比如struct my_dev里的成员是struct cdev cdev，那container_of(inode->i_cdev, struct my_dev, cdev)就没问题；如果传错了成员名，编译不会报错，但得到的基地址是错的，后续读写直接访问错误内存，而且这类错误很难一眼看出来。
还有一点：fops对整个驱动只需要一份，不要给每个实例拷贝一份fops。struct file_operations本身就是只读共享的，里面的open/read/write函数通过filp->private_data区分实例，这样设计才符合内核模型。
3.5 多实例还会碰到的其他坑
实践中比上面更细的坑还有几个，值得提前打个预防针。
第一个是寄存器映射。platform_driver如果需要在probe里映射寄存器，每个实例要各自映射自己的那一块地址。设备树节点里reg是按索引排列的，比如：
reg = <0x0 0xff3b0000 0x0 0x1000>, <0x0 0xff3b1000 0x0 0x100>;probe里分别用platform_get_resource(pdev, IORESOURCE_MEM, 0)和IORESOURCE_MEM, 1拿两个地址，再devm_ioremap_resource映射。每个实例映射的物理地址不同，映射出来的虚拟地址也互不相干。如果驱动里图省事把寄存器基址放在全局变量里，那多实例的场景几乎必炸——第二个probe把第一个的寄存器基址覆盖掉，第一个设备的所有寄存器读写全部打到第二个设备空间。
第二个是中断共享。如果多个设备实例恰好共享一条中断线，申请中断时要注意。普通情况下每个设备一个中断号，各自request_irq没问题。但有一些外设通过同一个GPIO扩展芯片的中断输出脚上报事件，多个设备共用同一个irq number。这种场景申请中断必须带IRQF_SHARED标志，并且dev_id不能传NULL：
ret = request_threaded_irq(irq, NULL, mychip_irq_thread, IRQF_TRIGGER_FALLING | IRQF_SHARED, dev_name(&client->dev), d); if (ret) return ret;多个驱动各自带着不同的dev_id注册到同一条中断线上，内核在中断到来时逐个调用各handler。你的handler要做一次“是否为我的设备中断”的判断（通常是读设备的INT状态寄存器），不是自己的中断就返回IRQ_NONE。free_irq时dev_id也要传一样的指针，用来精确释放自己的handler。这里如果传NULL，内核会拒绝free，因为一个irq线上可能挂着多个handler，不用dev_id就无法区分要释放哪一个。
第三个是资源清理顺序。devm确实能帮你释放内存和部分资源，但misc_register出来的miscdevice、device_create出来的设备节点、cdev_add出来的cdev，都需要在remove里手动清理。顺序建议是：先注销设备节点（misc_deregister / device_destroy + cdev_del），再释放动态申请的非devm内存。如果反过来，节点还在却先释放了内存，用户态恰好在remove期间打开节点，很容易触发use-after-free。
4. 瑞芯微板子上落地这两个技巧：验证清单与组合用法
4.1 设备树最小写法：同一总线挂两个同型号设备
以RK3568为例，I2C0总线上挂两颗同型号温度传感器，设备树最小写法如下：
&i2c0 { status = "okay"; clock-frequency = <400000>; sensor0: temp-sensor@48 { compatible = "mycorp,tmp-sensor"; reg = <0x48>; label = "board-temp"; interrupt-parent = <&gpio3>; interrupts = <RK_PA5 IRQ_TYPE_EDGE_FALLING>; }; sensor1: temp-sensor@49 { compatible = "mycorp,tmp-sensor"; reg = <0x49>; label = "cpu-temp"; interrupt-parent = <&gpio3>; interrupts = <RK_PA6 IRQ_TYPE_EDGE_FALLING>; }; };两颗设备compatible相同，i2c子系统会创建两个i2c_client，驱动probe被调用两次。每个节点的reg地址必须不同（I2C从地址），否则总线上操作系统无法区分。如果是平台设备，类似地写两个子节点，每个节点有自己的reg或interrupts，platform_bus也会生成两个platform_device。
如果你要让两个实例在用户态有可读性强的名字，建议利用label属性。在probe里读出来，而不是直接用dev_name那种0-0048格式：
const char *label = NULL; const char *node_name; node_name = dev_name(&client->dev); device_property_read_string(&client->dev, "label", &label); if (label) node_name = label;这样/dev下会出现board-temp、cpu-temp这种一看就懂的名字，对后续配应用程序很有帮助。
4.2 确认两个实例都正常 probe 的排查清单
多设备驱动最常见的调试场景就是“第二个设备为什么不工作”。我的排查顺序一般是这样的：
首先看dmesg。probe里如果有dev_info，正常情况应该看到两行类似mychip 0-0048: ...和mychip 0-0049: ...的日志。如果只看到一行，说明第二个节点的i2c_client可能就没生成，要检查设备树有没有被正确编译进dtb。
然后检查sysfs。I2C设备在/sys/bus/i2c/devices/下会有0-0048、0-0049两个目录，platform设备在/sys/bus/platform/devices/下能看到对应节点。如果目录存在但驱动没有绑定，目录下没有driver符号链接，那就是compatible或of_match_table没对上。
最后再看/sys/kernel/debug下的一些总线信息（如果内核开了DEBUG_FS）。这一层信息量大，但对于确认probe次数来说前两步已经足够。
如果你正在用模块方式调试，还要顺手检查一下modinfo mychip.ko | grep alias，确认of别名导出成功。否则设备树节点明明存在，modprobe也可能“假装”不知道要加载哪个模块。
4.3 两个技巧叠加使用的实际场景
前面两个技巧不是二选一的关系，实际项目中经常是叠加的。
比如RK3568的板子上有两路串口扩展芯片，一共挂了8路串口，其中两路芯片型号不同但功能相同。这种情况，型号差异用of_device_id.data去区分，每个型号对应一套寄存器参数；同型号的多个实例用每实例私有结构体去管理，每个实例有自己独立的保存状态和设备节点。probe里既能通过of_device_get_match_data拿到型号配置，又能通过devm_kzalloc拿到实例私有数据，两者互不冲突。
我给自己的一个开发纪律是：probe函数里第一件做的事是拿型号配置，第二件事是分配实例私有数据，第三件事才是解析设备树属性初始化硬件。顺序乱了，后面排查的时间会成倍增加。
多实例驱动的调试阶段，最好把每个实例的私有数据地址和关键参数打出来。虽然这种日志看起来很啰嗦，但多设备场景下“哪个实例对应哪份数据”非常容易搞混，日志里能明确区分，后续定位问题会轻松很多。
我个人的习惯是，probe里用dev_info打一行易于检索的实例信息，例如probe ok, model=A, name=board-temp，并在remove里打对应行。加上节点名和型号，开机日志里扫一眼就能确认系统里所有实例都正确注册和释放。这个习惯帮我在几次现场问题里省了大量时间，也推荐你试试。
最后再分享一个小技巧：新驱动第一次接多实例硬件时，别急着把功能全写完再验证。先只做probe和remove的框架，确认probe调用次数、私有数据结构、设备节点三个环节都对了，再往里填寄存器读写逻辑。这样一旦出问题，你很容易定位是匹配问题、实例管理问题还是硬件操作问题，而不是所有可能性搅在一起。这个顺序我踩过几次坑之后才固定下来，现在写多设备驱动基本一遍过。
