这是一个非常关键、也极易混淆的 Linux 内核驱动开发基础概念。`cdev` 和 `pdev` **完全不属于同一抽象层次，也不解决同一类问题** —— 它们分属内核中**两个正交的子系统**，用途、生命周期、注册方式、使用场景均截然不同。 下面用清晰对比 + 类比 + 代码示意的方式，彻底讲清本质区别： --- ### ✅ 一句话核心结论（先记住） > - `struct platform_device *pdev` 是 **“物理/虚拟设备”的内核表示**，属于 **Platform Bus 子系统**，描述“**硬件存在在哪里、有什么资源（IO/MEM/IRQ）**”； > - `struct cdev *cdev` 是 **“字符设备文件接口”的内核表示**，属于 **VFS（虚拟文件系统）子系统**，描述“**用户空间如何通过 `/dev/xxx` 访问该设备（open/read/write/ioctl 等）**”。 👉 它们的关系是：**一个 platform_device（pdev）通常需要一个或多个 cdev 来向用户空间暴露操作接口**。 👉 就像： > 🏗️ `pdev` = 工厂里的一台 CNC 数控机床（真实硬件，有电源、控制板、IO端口） > 💻 `cdev` = 工厂门口的“操作员终端”（键盘+屏幕），工人通过它下发 G 代码、读取状态 —— **没有终端，机床存在但无法被软件控制** --- ### 🔍 详细对比表 | 维度 | `struct platform_device *pdev` | `struct cdev *cdev` | |------|-------------------------------|----------------------| | **所属子系统** | Platform Bus（总线驱动模型） | VFS / Char Device Layer（字符设备框架） | | **本质** | **设备实体的内核抽象**（描述“硬件是什么、在哪、有何资源”） | **设备访问接口的内核抽象**（描述“用户如何用文件操作访问它”） | | **生命周期起点** | 由内核在启动时解析 DT/ACPI 或由板级代码 `platform_device_register()` 创建 | 由驱动开发者在 `.probe()` 中 `cdev_init()` + `cdev_add()` 显式创建 | | **关键字段** | `.name`, `.id`, `.resource[]`（IO/MEM/IRQ 资源数组）, `.dev.of_node`（DT 节点） | `.ops`（`file_operations` 函数指针表：`.open`, `.read`, `.write`, `.ioctl` 等）, `.owner`（模块所有权） | | **注册函数** | `platform_device_register()`（手动）<br>或由内核自动（DT/ACPI 枚举） | `cdev_add()`（必须在 `cdev_init()` 后调用） | | **用户空间可见性** | ❌ 完全不可见（纯内核内部对象） | ✅ 可见：`mknod /dev/mydev c MAJOR MINOR` 或由 udev 自动创建 `/dev/mydev` | | **典型使用位置** | 驱动的 `.probe(struct platform_device *pdev)` 参数 | 驱动的 `.probe()` 中分配、初始化、添加；其 `.ops` 函数在用户 `open("/dev/xxx")` 时被内核调用 | | **是否需要主次设备号？** | ❌ 不需要 | ✅ 必须：通过 `register_chrdev_region()` 或 `alloc_chrdev_region()` 获取，`cdev_add()` 时绑定 | | **和文件系统关系** | 无直接关系（不涉及 VFS） | 直接桥接 VFS：`/dev/xxx` 是 VFS inode，指向此 `cdev` 的 `.ops` | --- ### 🧩 典型协作流程（以 `dw-apb-uart` 驱动为例说明） 虽然 `dw8250` 是串口驱动，**它本身不直接使用 `cdev`**（而是基于更上层的 `serial_core` 框架，该框架内部封装了 `cdev`），但我们可以用一个简化字符驱动来直观演示 `pdev` 和 `cdev` 如何配合： #### ✅ 示例：一个基于 platform device 的 LED 驱动（伪代码） ```c // 1. 定义 platform_device（通常在板级代码或 DT 中，内核自动创建） // DT: led@12340000 { compatible = "mycompany,led"; reg = <0x12340000 0x100>; }; // 2. 驱动 probe 函数中： static int myled_probe(struct platform_device *pdev) // ← pdev 来自内核匹配 { struct resource *res; struct myled_data *led; int ret; // 【Step A】从 pdev 解析硬件资源（这才是 pdev 的核心价值！） res = platform_get_resource(pdev, IORESOURCE_MEM, 0); // 得到寄存器基址 led->base = devm_ioremap(&pdev->dev, res->start, resource_size(res)); led->irq = platform_get_irq(pdev, 0); // 得到中断号 // 【Step B】申请并初始化 cdev（暴露用户接口） cdev_init(&led->cdev, &myled_fops); // 绑定 file_operations led->cdev.owner = THIS_MODULE; ret = alloc_chrdev_region(&led->devno, 0, 1, "myled"); // 分配主次设备号 if (ret) return ret; ret = cdev_add(&led->cdev, led->devno, 1); // ← 注册 cdev！用户 now can access /dev/myled if (ret) goto err_cdev; // 【Step C】保存 pdev → cdev 关联（重要！） platform_set_drvdata(pdev, led); // 把 led 数据存到 pdev，供后续 ioctl 使用 return 0; } // 用户调用 open("/dev/myled") → 内核调用 myled_fops.open() static int myled_open(struct inode *inode, struct file *file) { struct myled_data *led; // 【关键】从 file->private_data 或全局找到对应 led 实例 // 通常：led = container_of(inode->i_cdev, struct myled_data, cdev); // 或更安全：led = platform_get_drvdata(...); ← 这就需要 probe 时存过 pdev! ... } ``` ✅ 在这里： - `pdev` 提供了 **硬件地址、中断号等底层信息**（没有它，驱动不知道控制哪块寄存器）； - `cdev` 提供了 **`/dev/myled` 这个入口**（没有它，用户程序连 `open()` 都无法调用）； - 二者通过 `platform_set_drvdata()` / `platform_get_drvdata()` **关联起来**，使用户态操作能最终作用于真实硬件。 --- ### ❗ 常见误解澄清 | 误解 | 正解 | |------|------| | “`cdev` 是设备驱动” | ❌ `cdev` 只是**接口载体**；真正的驱动逻辑在 `.probe()`（用 `pdev` 初始化硬件）和 `.fops` 函数（用 `cdev` 暴露功能）中 | | “`pdev` 和 `cdev` 是一对一” | ⚠️ 不一定。一个 `pdev`（如 SoC 上的 UART 控制器）可能对应 **多个 `cdev`**（如 `/dev/ttyS0`, `/dev/ttyS1`）；一个 `cdev` 也可能由非 `pdev` 的设备创建（如 `miscdevice`、`input_dev`） | | “只要注册了 `cdev`，设备就能用” | ❌ 必须先有 `pdev`（或类似机制）完成硬件初始化（时钟、复位、寄存器配置），否则 `cdev` 的 `.read/.write` 会操作无效地址，导致 kernel panic | --- ### ✅ 总结：一张图看懂关系 ``` 用户空间 │ ▼ open("/dev/ttyS0") → read() → ioctl() │ 内核 VFS 层 │ ← 绑定到 cdev.ops（file_operations） ▼ [struct cdev] ────────────────┐ │ │ │ .ops = &uart_ops │ │ .owner = THIS_MODULE │ │ │ ▼ │ [struct uart_8250_port] │ ← dw8250 驱动中，serial8250_register_8250_port() 内部创建了 cdev │ │ │ .port.membase = ... │ ← 这个值从哪里来？→ 从 pdev！ │ .port.irq = ... │ ▼ │ [struct platform_device *pdev] ← dw8250_probe() 的参数！ │ ├─ .resource[0] = <0xff010000 0x100> → membase 来源 ├─ .irq = 34 → irq 来源 └─ .dev.of_node → "snps,dw-apb-uart" → 匹配依据 ``` ---