这是一个**极其精准、直击要害的问题**。你提供的这段 `dw-apb-uart` 驱动代码，**表面上看没有显式出现 `struct cdev` 或 `cdev_init()`/`cdev_add()` 调用**，但它**绝对依赖并完整使用了 `pdev` 和 `cdev` 的协作机制** —— 只是这种协作被 **`serial_core` 子系统（即 `8250_core`）深度封装和抽象了**。 下面我将**逐行定位、精准指出 `pdev` 和 `cdev` 在本驱动中的具体体现、绑定关系与数据流向**，彻底解开这个“看不见的 `cdev`”之谜： --- ### ✅ 结论先行（先记住） > 🔑 **`pdev` 体现在 `dw8250_probe(struct platform_device *pdev)` 的参数中，并贯穿整个 probe 流程；** > 🔑 **`cdev` 不在本文件中显式定义，而是由 `serial8250_register_8250_port()` 内部自动创建并注册；** > 🔑 **二者通过 `struct uart_8250_port`（继承自 `struct uart_port`）强绑定：`uart_port.dev = &pdev->dev`，且 `uart_port.line` 决定 `/dev/ttySx` 设备号。** --- ## 🔍 一、`pdev` 的体现：无处不在的硬件载体 `pdev` 是整个驱动的**起点和根基**，它出现在以下关键位置： | 位置 | 代码片段 | 说明 | |--------|-----------|------| | **`.probe()` 函数签名** | `static int dw8250_probe(struct platform_device *pdev)` | ✅ 最直接体现：`pdev` 是内核传入的、已匹配成功的设备描述符 | | **资源获取** | `platform_get_resource(pdev, IORESOURCE_MEM, 0)`<br>`platform_get_irq(pdev, 0)` | ✅ 从 `pdev` 解析出寄存器地址、中断号等硬件资源 —— 这是驱动操作真实 UART 的唯一依据 | | **设备信息绑定** | `p->dev = dev;` （其中 `dev = &pdev->dev`）<br>`platform_set_drvdata(pdev, data);` | ✅ 将 `uart_port` 和 `dw8250_data` 关联到 `pdev`，为后续 `platform_get_drvdata()` 拿回私有数据做准备 | | **电源管理** | `pm_runtime_set_active(dev);`<br>`pm_runtime_enable(dev);` | ✅ `dev` 即 `&pdev->dev`，Runtime PM 直接作用于 platform device | | **唤醒配置** | `device_init_wakeup(&pdev->dev, true);` | ✅ 显式对 `pdev` 启用 wakeup 功能 | ✅ **`pdev` 的核心价值在此驱动中体现为：提供 `membase`（IO 地址）、`irq`（中断号）、`dev`（设备对象）、`of_node`（DT 节点）—— 没有它，驱动连寄存器都找不到。** --- ## 🔍 二、`cdev` 的体现：藏在 `serial8250_register_8250_port()` 的黑盒中 这是最关键的洞察！本驱动**没有自己写 `cdev_init()`**，而是调用了 **`serial8250_register_8250_port()`** —— 这个函数是 `8250_core.c`（`drivers/tty/serial/8250/8250_core.c`）中的核心注册函数，它**内部完成了 `cdev` 的全部工作**。 我们来追踪它的调用链和内部逻辑： ### ✅ 步骤 1：驱动中调用注册入口 ```c // dw8250_probe() 中： data->data.line = serial8250_register_8250_port(up); // ← 关键！传入的是 struct uart_8250_port * ``` - `up` 是一个栈上定义的 `struct uart_8250_port uart = {}`，其基类 `struct uart_port *p = &up->port` 已被初始化（含 `p->dev = &pdev->dev`, `p->membase`, `p->irq` 等）。 ### ✅ 步骤 2：`serial8250_register_8250_port()` 内部做了什么？（简化逻辑） 该函数最终会调用 `uart_add_one_port()` → `uart_configure_port()` → **`uart_cdev_add()`**。 而 `uart_cdev_add()` 的核心代码（来自 `drivers/tty/serial/8250/8250_core.c`）如下： ```c // 简化示意（非原始代码，但逻辑等价） static int uart_cdev_add(struct uart_driver *drv, struct uart_state *state, int line) { struct cdev *cdev = &state->cdev; // ← 看！每个 uart_state 都有一个内嵌 cdev！ dev_t devt = MKDEV(drv->major, drv->minor + line); cdev_init(cdev, &uart_fops); // ← 绑定 file_operations！ cdev->owner = drv->owner; cdev->dev = devt; return cdev_add(cdev, devt, 1); // ← 注册 cdev！用户 now can open("/dev/ttySx") } ``` ✅ 所以： - `cdev` 是 **`struct uart_state` 的一个成员字段**（`state->cdev`），而 `uart_state` 是 `serial8250_register_8250_port()` 内部为每个串口线（`line`）动态分配的； - `file_operations` 是固定的 `uart_fops`（定义在 `drivers/tty/serial/serial_core.c`），它实现了 `open/read/write/ioctl` 等，最终调用 `uart_port` 的 `.ops`（如 `dw8250_handle_irq` 是中断处理，不在此 `fops` 中，但 `read/write` 会调用 `uart_port` 的底层读写函数）； - 设备号 `/dev/ttySx` 的主次设备号由 `uart_driver`（如 `serial8250_reg`）统一管理，`line` 值决定 `x`（`ttyS0`, `ttyS1`...）。 ### ✅ 步骤 3：`pdev` 和 `cdev` 如何关联？—— 通过 `struct uart_port` `struct uart_port` 是连接二者的**核心桥梁结构体**： ```c struct uart_port { ... struct device *dev; // ← 指向 &pdev->dev！这是关联的根源！ unsigned long mapbase; // ← 来自 pdev->resource void __iomem *membase; // ← ioremap(p->mapbase)，也来自 pdev unsigned int irq; // ← 来自 platform_get_irq(pdev, 0) ... }; ``` - 当用户执行 `open("/dev/ttyS0")` → VFS 调用 `uart_fops.open()` → `uart_open()` → 根据设备号找到 `uart_state` → 找到 `uart_port` → **通过 `port->dev` 拿到 `&pdev->dev`** → 进而通过 `platform_get_drvdata(port->dev)` 拿到 `dw8250_data *` → 最终调用 `dw8250_handle_irq` 等函数。 ✅ **这就是 `pdev` 和 `cdev` 的完整绑定链：** `/dev/ttyS0` (cdev) → `uart_fops.open()` → `uart_state` → `uart_port` → `port->dev == &pdev->dev` → `platform_get_drvdata(port->dev) == dw8250_data *` → `p->serial_in/p->serial_out` 等操作真实硬件（寄存器） --- ## 🔍 三、可视化数据流图（`pdev` ↔ `cdev`） ``` 用户空间 │ ▼ open("/dev/ttyS0") → read() → ioctl() │ 内核 VFS 层 │ ← 绑定到 uart_fops（由 serial_core 提供） ▼ [struct cdev] ←───────────────────────────────┐ │ │ │ .ops = &uart_fops │ │ .dev = MKDEV(major, minor+0) │ ▼ │ [struct uart_state] │ │ │ │ .port = &up->port │ ← dw8250_probe() 中传入的 up ▼ │ [struct uart_8250_port] │ │ │ │ .port.dev = &pdev->dev ←←←←←←←←←←←←←←←←←←┘ （关键绑定！） │ .port.membase = ioremap(regs->start) ← 来自 pdev->resource │ .port.irq = platform_get_irq(pdev, 0) ← 来自 pdev ▼ [struct platform_device *pdev] ← dw8250_probe() 参数 │ ├─ .name = "dw-apb-uart" → 匹配 driver.of_match_table ├─ .resource[0] = <0xff010000 ...> → 提供 membase └─ .dev.of_node → DT node with "snps,dw-apb-uart" ``` --- ## ✅ 四、为什么这样设计？（设计哲学） | 问题 | 答案 | |------|------| | **Q：为何不自己写 `cdev`？** | A：`serial_core` 是 Linux 串口驱动的**标准框架**，它统一处理：设备号分配、`/dev/ttySx` 创建、`termios` 设置、DMA 支持、TTY 层对接、多端口管理。重复造轮子既危险又冗余。 | | **Q：`pdev` 和 `cdev` 谁先注册？** | A：`pdev` 由内核在启动时（DT/ACPI 解析后）自动注册；`cdev` 在 `dw8250_probe()` 被调用后，由 `serial8250_register_8250_port()` **动态创建并注册**。顺序严格：先有 `pdev`，才有 `cdev`。 | | **Q：如果 `pdev` 匹配失败，`cdev` 会存在吗？** | A：❌ 不会。`serial8250_register_8250_port()` 只在 `dw8250_probe()` 成功执行后才调用，而 `probe` 仅在 `pdev` 匹配成功时触发。 | --- ## ✅ 五、验证：如何在运行时确认？ 你可以通过以下命令验证 `pdev` 和 `cdev` 的存在与关联： ```bash # 1. 查看 platform device 是否存在（pdev） $ ls /sys/devices/platform/ | grep uart # 或查看 DT 节点 $ cat /proc/device-tree/serial@ff010000/compatible snps,dw-apb-uart # 2. 查看 cdev 是否注册（对应 /dev/ttySx） $ ls -l /dev/ttyS* crw------- 1 root root 4, 64 Jan 1 00:00 /dev/ttyS0 # 3. 查看主设备号（4）对应的 cdev $ cat /proc/devices | grep " 4 " 4 ttyS # 4. 查看该 cdev 的 owner（即 uart_driver） $ ls /sys/class/tty/ ttyS0 ttyS1 ... $ cat /sys/class/tty/ttyS0/device/name # 应显示 "serial8250" $ cat /sys/class/tty/ttyS0/device/of_node/compatible # 应显示 "snps,dw-apb-uart" ``` ✅ 输出证明：`/dev/ttyS0`（cdev）的 `device` 目录指向的就是 `pdev` 的 sysfs 节点！ ---