第4章：平台驱动与设备树

面试问题：设备树中 compatible 属性的作用是什么？驱动是如何匹配的？

面试官考察点：是否理解设备树与驱动的绑定机制；能否讲清 of_match_table 与 compatible 的匹配逻辑；对多平台兼容性的处理经验。

回答框架：① 定义 compatible 为设备“身份证”，格式 "厂商,型号"；② 简述匹配顺序：内核遍历 of_match_table → 优先精确匹配 → 退而使用 compatible 中第一个条目；③ 配合 platform_driver 注册函数说明整体流程。

简短示例回答：“compatible 是设备树中标识设备型号的字符串，格式'厂商,型号'。驱动通过 of_match_table 定义兼容列表，内核在设备树中查找匹配条目后即绑定 platform_device 与 platform_driver。我曾在移植驱动时仅修改 dts 文件即可适配不同 SoC，大大减少代码改动。”

可能追问：如果 compatible 包含多个值，内核优先匹配哪个？板级文件与 dtb 的关系是什么？如何调试设备树匹配失败？

面试问题：设备树中如何获取一个字符串数组属性？用哪个 API？

面试官考察点：是否熟练掌握 of_property_read_xxx 家族函数；对 prop->length、of_find_property 等底层 API 的熟悉程度；处理属性不存在或格式错误的健壮性。

回答框架：① 明确需求：获取字符串数组（如驱动支持的设备列表）；② 推荐 of_property_read_string_index() 遍历索引；③ 可先用 of_property_count_strings() 获取数量；④ 处理负值返回错误码。

简短示例回答：“使用 of_property_count_strings() 获取数量，再循环调用 of_property_read_string_index() 逐个读取。例如解析 interrupts-names 时需保证索引越界返回 -ENODATA。我习惯在 probe 入口统一解析所有 dts 属性并做完整性校验。”

可能追问：of_property_read_string 与 of_property_read_string_index 的区别？如何读取整型数组？为什么推荐在 probe 阶段一次性解析？

面试问题：设备树中 reg 属性如何解析？地址和大小分别是多少？

面试官考察点：对#address-cells、#size-cells的理解；实际解析时地址与大小位数判断；多段reg（如多寄存器空间）的处理方式。

回答框架：① 说明 devicetree 中 reg 由 address-cells 和 size-cells 决定步长；② 使用 of_address_to_resource() 或 platform_get_resource() 直接获取 struct resource；③ 描述多区段 reg 的索引读取方法。

简短示例回答：“通常用 platform_get_resource(pdev, IORESOURCE_MEM, 0) 获取第一个寄存器区段。更灵活的方式是通过 of_address_to_resource(node, index, &res)。我曾遇到地址宽度配置错误导致驱动无法 probe，排查发现根节点#size-cells 被误设为2。”

可能追问：of_iomap 与 platform_get_resource + ioremap 的区别？如何读取以物理地址方式描述的 reg？