设备树兼容性策略：compatible属性的匹配原则与向后兼容写法
设备树版本升级中，最让我头疼的问题是什么？不是语法错误，也不是节点缺失，而是 compatible 属性的兼容性。我见过太多因为 compatible 写得不规范，导致新内核驱动无法匹配旧设备树，或者旧内核驱动无法识别新设备树的案例。说白了，compatible 就是驱动和设备树之间的“接头暗号”，暗号对不上，系统就起不来。
compatible 属性的匹配原则
compatible 属性的核心作用，是告诉内核：这个设备是什么，以及它能兼容哪些驱动。它的匹配原则其实很简单，但很多人容易忽略细节。
1. 匹配顺序：从最具体到最通用
内核在匹配驱动时，会按照 compatible 属性中字符串的从左到右顺序进行匹配。第一个字符串通常是最具体的设备型号，后面的字符串是它兼容的通用型号。
核心原则：compatible 的字符串顺序，决定了驱动的匹配优先级。越具体的型号放越前面，越通用的放越后面。
举个例子，我在一个项目中遇到过这样的设备树节点：
// 设备树中的 compatible 写法
compatible = "ti,am335x-uart", "ti,omap3-uart";内核会先尝试匹配 "ti,am335x-uart" 这个驱动。如果找不到，再尝试匹配 "ti,omap3-uart"。这种写法意味着：AM335x 的 UART 硬件上兼容 OMAP3 的 UART，但有一些 AM335x 特有的寄存器或功能。
2. 厂商前缀：必须规范化
compatible 字符串的格式是 "厂商,设备型号"。厂商前缀必须使用内核官方维护的 vendor-prefixes.txt 中定义的字符串。我自己就踩过这个坑——有一次我写了个 "mycompany,mydevice"，结果内核社区 review 时直接打回，因为 "mycompany" 不在官方前缀列表中。
| 正确写法 | 错误写法 | 说明 |
|---|---|---|
"ti,am335x-uart" |
"ti_am335x_uart" |
厂商和设备之间必须用逗号，不能用下划线 |
"fsl,imx6q-uart" |
"imx6q-uart" |
缺少厂商前缀，可能导致命名冲突 |
"brcm,bcm2835-uart" |
"broadcom,bcm2835-uart" |
厂商前缀必须使用官方缩写 |
向后兼容的写法：版本升级的护身符
版本升级时，最怕的就是新内核不认旧设备树，或者旧内核不认新设备树。向后兼容的写法，说白了就是让新旧版本都能正常工作。我总结了几种实战中常用的策略。
策略一：保留旧 compatible 字符串
这是最直接的方法。升级驱动时，不要删除旧的 compatible 字符串，而是把新的加在前面。
// 旧版本设备树
compatible = "vendor,old-device-v1";
// 新版本设备树（向后兼容）
compatible = "vendor,new-device-v2", "vendor,old-device-v1";这样，新内核会优先匹配 v2 驱动，旧内核也能通过 v1 字符串匹配到老驱动。我曾经在一个项目中，因为删除了旧的 compatible 字符串，导致客户升级内核后，旧设备树无法启动。嗯，那次教训挺深刻的。
策略二：驱动中同时支持新旧 compatible
在驱动代码中，需要同时注册新旧 compatible 字符串的匹配表。以 Linux 内核的 platform_driver 为例：
static const struct of_device_id my_driver_of_match[] = {
{ .compatible = "vendor,new-device-v2", .data = &new_device_data },
{ .compatible = "vendor,old-device-v1", .data = &old_device_data },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, my_driver_of_match);这里要注意，新旧设备的数据结构可能不同。我在实际项目中，通常会在 .data 字段中存放不同版本的硬件配置信息，然后在 probe 函数中根据匹配到的 compatible 字符串，选择不同的初始化路径。
我的习惯：在驱动 probe 函数中，通过 of_match_device() 获取匹配到的 of_device_id，然后根据其中的 .data 指针区分不同版本。这样代码结构清晰，也方便后续维护。
策略三：使用设备树 overlay 做兼容层
如果硬件改动较大，无法通过简单的 compatible 字符串兼容，可以考虑使用设备树 overlay。overlay 可以在不修改原始设备树的情况下，添加或修改节点属性。
// overlay 文件：fix-old-device.dtso
/dts-v1/;
/plugin/;
&old_device_node {
compatible = "vendor,new-device-v2", "vendor,old-device-v1";
new-property = <0x12345678>;
};这种方式的好处是：原始设备树保持不变，overlay 在启动时动态加载。我在一个客户现场调试时用过这招——他们的 bootloader 不支持更新设备树，我就写了个 overlay 文件，通过内核参数加载，完美解决了兼容性问题。
实战中的避坑指南
我曾经踩过的坑：
- compatible 字符串拼写错误：有一次我把 "am335x" 写成了 "am3350"，内核死活匹配不上。检查了三天才发现是拼写问题。
- 忘记更新驱动匹配表：设备树改了 compatible，但驱动中的 of_match_table 没更新，导致驱动无法加载。
- 新旧设备数据结构不兼容：新版本改了寄存器布局，但旧设备树没有对应的属性，驱动 probe 时直接崩溃。
我的建议是：每次修改 compatible 时，都要同步检查三处——设备树源文件、驱动匹配表、硬件数据结构。这三处必须保持一致。
兼容性策略的决策流程
下面这张图，是我在项目中总结的兼容性策略选择流程。每次做版本升级时，我都会对照这张图走一遍。
总结一下
compatible 属性的兼容性策略，说白了就是三句话：
- 写全写规范：厂商前缀必须官方，字符串顺序从具体到通用。
- 保留旧兼容：升级时不要删除旧的 compatible 字符串，新的放前面。
- 同步更新驱动：设备树改了，驱动匹配表和数据结构必须跟着改。
你想想看，如果每个版本升级都遵循这三条原则，设备树兼容性问题至少能减少 80%。我在多个项目中验证过这个结论，确实有效。