先把三张“地图”分开
软件调用关系、Linux 设备树形关系、硬件事务路径有关联，但不是同一张图。主机驱动负责建立通路，不会替每一笔 DMA 搬数据。
01
案例：HiFive Unmatched / FU740 的主线主机实现，外接 NVMe SSD。板上有 PCIe Switch（交换芯片）；主图将其中间端口与总线折叠，详细逻辑拓扑见第 02 章。不把示意 BDF、链路宽度或服务能力当成实测结果。
同一系统，三个视角
点击方框，查看职责、对象与源码
RC = Root Complex（根复合体，主机侧）；EP = Endpoint（端点）；DWC = DesignWare Controller；TLP = Transaction Layer Packet（PCIe 事务层包）；NVMe 是使用 PCIe 的存储命令协议。图中实线/虚线不代表实际芯片模块边界。
软件控制：可含回调对象关联：不是直接调用硬件 MMIO 事务
三行分别阅读：同一列上下的方框不表示一一对应。对象行的灰线仅概括关联，真实桥/总线层级见第 02 章。
从 FU740 平台驱动开始
点击上方任一节点，查看它是谁、谁使用它，以及它不负责什么。
控制面：先把设备“建立起来”
启动
平台匹配 → 上电/复位/链路 → 注册主机桥 → 扫描 PCI 拓扑。
配置
分配 BAR 与桥窗口、配置中断、绑定功能驱动、创建队列。
管理
错误处理、功耗、恢复和移除；有些属于端口服务，有些属于 PCI core。
数据面：建立后由硬件运行
CPU → 设备
MMIO（内存映射 I/O）访问 BAR，例如写 NVMe doorbell（门铃）。
设备 ↔ 主存
DMA（直接内存访问）读取命令、搬运数据、写完成队列。
设备 → CPU
MSI/MSI-X（消息中断）经主机中断层路由，CPU 进入 NVMe 完成处理。
阅读目标：能说清“哪个对象和哪个驱动绑定”“哪个 API 只建立映射”“真正的 PCIe 请求由谁发起”。
设备、驱动和公共库，不要混成一类
SoC 控制器先在 platform 总线上绑定；链路另一侧的端点通过 PCI 枚举发现。DWC 是这条主机驱动路径中的公共实现，不是第三个必须独立 probe 的设备。
02
启动控制流：从描述硬件到可提交 I/O
按阶段单步；实线调用、函数指针回调、driver core 绑定和 workqueue 异步执行分别标注。它们不是一条连续的同步调用栈。
03
一次 NVMe I/O，究竟是谁在搬数据？
同一套队列机制，READ 和 WRITE 的有效载荷方向不同。这里的 READ / WRITE 是 NVMe 存储命令，不是直接指 CPU load/store。
04
服务与相互影响：框架能力不等于板级启用
PCIe 端口服务是严格的内核对象模型；DMA、MSI、ASPM 则是相关机制，并不是都挂在 pcie_port_bus 上。
05
固定版本的源码索引
所有链接基于 torvalds/linux 的 v6.6 标签。关键入口提供行号；网页内容离线可读，打开外部完整源码需要联网。
06