`platform_driver` 是 **Linux 内核中“平台总线（Platform Bus）”子系统的核心抽象之一**，它代表一个**可被 platform bus 自动匹配并管理的设备驱动程序**。它是 Linux 设备驱动模型（Device Driver Model）中实现 **“设备与驱动分离”、“硬件无关性” 和 “热插拔友好”** 的关键机制。 下面我将用**本质定义 → 核心结构 → 工作原理 → 代码实证 → 常见误区**五层递进方式，彻底讲清 `platform_driver` 是什么、为什么需要它、它如何工作。 --- ### ✅ 一、一句话本质定义（先记住） > `struct platform_driver` 是 **内核中对“一类不归属于标准总线（如 PCI/USB/I2C）的片上外设驱动”的统一封装**，它不直接操作硬件，而是通过 **匹配 `struct platform_device`（描述硬件存在）→ 获取资源 → 初始化硬件 → 注册用户接口（如 cdev）**，最终让上层软件能安全、标准地使用该硬件。 👉 类比： - `platform_device` = 工厂里贴了标签的 CNC 机床（型号、IP 地址、电源端口编号）； - `platform_driver` = 该机床的**标准操作手册 + 维修指南 + 远程控制 SDK**； - `platform_bus` = 工厂的**中央调度系统**，负责把“手册”发给匹配的“机床”。 --- ### ✅ 二、核心结构体：`struct platform_driver` 定义在 `<linux/platform_device.h>`，关键字段如下： ```c struct platform_driver { int (*probe)(struct platform_device *); // ← 最重要！设备匹配成功后调用，做初始化 int (*remove)(struct platform_device *); // ← 设备卸载时调用，做清理 void (*shutdown)(struct platform_device *); // 关机前调用 int (*suspend)(struct device *); // 休眠前（可选） int (*resume)(struct device *); // 唤醒后（可选） struct device_driver driver; // ← 继承自通用 driver，含 name、owner、of_match_table 等 // 下面三个是便捷宏封装，实际用不到（推荐用 driver.of_match_table） const struct platform_device_id *id_table; // 用于 .driver.name 匹配（已过时） bool prevent_deferred_probe; // 防止 probe 被 defer（调试用） }; ``` #### 🔑 关键点解析： | 字段 | 说明 | |------|------| | `.probe()` | **驱动的灵魂函数**。参数 `struct platform_device *pdev` 就是内核找到的、与该驱动匹配的硬件设备。在此函数中：获取寄存器地址、申请中断、使能时钟、注册 `cdev`/`miscdevice`、保存私有数据（`platform_set_drvdata()`）。✅ 你看到的 `dw8250_probe()` 就是它的实现。 | | `.remove()` | `probe` 的逆过程：释放内存、禁用时钟、取消中断、注销 `cdev`。✅ `dw8250_remove()` 即此。 | | `.driver` | **继承自 `struct device_driver`**，包含：<br>• `.name`：驱动名（如 `"dw-apb-uart"`），用于 `/sys/bus/platform/drivers/xxx` 目录名；<br>• `.owner`：模块所有权（`THIS_MODULE`）；<br>• `.of_match_table`：**DT 匹配表**（最常用！见下文）；<br>• `.acpi_match_table`：ACPI 匹配表（x86 常用）。 | | `.id_table` | 旧式匹配方式（基于 `pdev->name` 字符串匹配），**已被 of_match_table 取代，不推荐使用**。 | --- ### ✅ 三、工作原理：Platform Bus 如何“牵线搭桥”？ 整个流程是 **内核自动完成的**，无需驱动开发者手动调用： ```mermaid graph LR A[内核启动] --> B[解析 Device Tree / ACPI] B --> C[为每个 compatible=xxx 的节点创建 platform_device] C --> D[遍历所有已注册的 platform_driver] D --> E{driver.of_match_table 是否匹配 pdev.of_node?} E -- 是 --> F[调用 driver.probe(pdev)] E -- 否 --> G[跳过] F --> H[probe 成功：设备就绪<br>probe 失败：打印 error，设备不可用] ``` #### 🔍 匹配规则（以 DT 为例）： - 驱动定义： ```c static const struct of_device_id dw8250_of_match[] = { { .compatible = "snps,dw-apb-uart" }, // ← 关键！必须与 DT 中一致 { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, dw8250_of_match); ``` - DT 节点： ```dts &serial0 { compatible = "snps,dw-apb-uart"; // ← 完全相同！匹配成功 ✅ reg = <0x0 0xff010000 0x0 0x100>; interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>; ... }; ``` - 内核行为： 当 `platform_driver_register(&dw8250_platform_driver)` 执行后，内核会扫描所有 `platform_device`，对每个 `pdev->dev.of_node`，用 `of_match_node(dw8250_of_match, pdev->dev.of_node)` 比较 `compatible` 字符串 —— **完全相等即匹配**。 ✅ 匹配成功后，`dw8250_probe()` 被调用，`pdev` 参数就是这个 `&serial0` 设备。 --- ### ✅ 四、代码实证：`dw8250` 驱动中的 `platform_driver` 你提供的代码末尾有： ```c static struct platform_driver dw8250_platform_driver = { .driver = { .name = "dw-apb-uart", // ← sysfs 目录名：/sys/bus/platform/drivers/dw-apb-uart .pm = &dw8250_pm_ops, .of_match_table = dw8250_of_match, // ← DT 匹配表（核心！） .acpi_match_table = dw8250_acpi_match, }, .probe = dw8250_probe, // ← 硬件初始化入口 .remove = dw8250_remove, // ← 清理入口 }; module_platform_driver(dw8250_platform_driver); // 等价于： // static int __init dw8250_init(void) { return platform_driver_register(&dw8250_platform_driver); } // static void __exit dw8250_exit(void) { platform_driver_unregister(&dw8250_platform_driver); } ``` #### ✅ 这段代码完成了： - ✅ 注册一个名为 `"dw-apb-uart"` 的 platform driver； - ✅ 声明它支持 `compatible = "snps,dw-apb-uart"` 的设备； - ✅ 提供 `probe/remove` 函数处理生命周期； - ✅ 通过 `module_platform_driver()` 宏自动处理 `init/exit`。 --- ### ✅ 五、常见误区澄清（非常重要！） | ❌ 误解 | ✅ 正解 | |---------|----------| | “`platform_driver` 是硬件驱动本身” | ❌ 不是。它是**驱动的元信息容器**。真正的硬件操作在 `.probe()` 里（如 `ioremap`, `request_irq`），而 `.probe()` 只是函数指针。`platform_driver` 本身不占内存、不操作寄存器。 | | “`platform_driver` 和 `platform_device` 是一一对应的” | ⚠️ 不一定。一个 `driver` 可匹配多个 `pdev`（如 4 个 UART 控制器都用 `dw-apb-uart` 驱动）；一个 `pdev` 只能被一个 `driver` probe（排他性匹配）。 | | “没有 `platform_device` 就不能用 `platform_driver`” | ✅ 正确！`platform_driver` 是“被动等待者”。它注册后静静待命，直到内核发现一个 `compatible` 匹配的 `pdev`，才触发 `probe`。没有 `pdev`，`driver` 就是“空壳”。 | | “`platform_driver` 只能用于 SoC 片上外设” | ✅ 基本正确。它专为 **无物理总线（PCI/USB）、无热插拔能力、由 SoC 集成、地址固定** 的设备设计（UART, I2C controller, GPIO controller, PWM, etc.）。USB 设备用 `usb_driver`，I2C 设备用 `i2c_driver`。 | --- ### ✅ 六、`platform_driver` 在 sysfs 中的表现 一旦注册成功，你会在以下路径看到它： ```bash # 驱动目录（driver 本身） /sys/bus/platform/drivers/dw-apb-uart/ ├── bind # 手动绑定设备（调试用） ├── uevent ├── unbind # 手动解绑 └── module -> ../../../module/dw8250 # 指向加载的模块 # 设备目录（被它驱动的 pdev） /sys/devices/platform/serial@ff010000/ ├── driver -> ../../../bus/platform/drivers/dw-apb-uart # ← 关键！双向链接 ├── of_node/... └── resources # 显示 IO/MEM/IRQ 资源（来自 pdev->resource） ``` ✅ `driver` 和 `pdev` 之间通过 **符号链接** 实现双向关联，这是内核设备模型的基石。 --- ### ✅ 总结：`platform_driver` 是什么？（再浓缩） > `platform_driver` 是 **Linux 内核为“静态集成、地址固定、无标准总线”的片上外设（如 UART、GPIO、TIMER）提供的一套标准化驱动注册与匹配框架**。 > 它本身不干活，但通过 `.probe()` 函数接收 `platform_device`（硬件描述），从而获得操作硬件所需的一切（地址、中断、时钟），再调用底层 API（`ioremap`, `request_irq`, `cdev_add`）完成驱动功能。 > **它是连接“硬件存在”（pdev）和“软件可用”（/dev/ttyS0）的桥梁。** ---