3.2 访问内核中的硬件 I/O 内存

让我们直接切入正题。

作为一个驱动作者，你会反复面临这样一个场景：你需要直接操控外设芯片上的寄存器或内存。这就是我们所谓的「I/O 内存」。在底层驱动开发中，这其实就是最核心的工作——通过向这些寄存器发指令来编程硬件。

但这里有个坑。在 Linux 里，你想直接访问这些硬件 I/O 内存？没那么容易。

理解直接访问的困境

你要明白一个事实：硬件芯片上的这些 I/O 内存，绝不是普通的 RAM。

Linux 内核会严词拒绝模块或驱动作者对这些硬件 I/O 内存位置的直接访问。为什么？我们在上一本书《Linux Kernel Programming》的第 7 章里详细讲过——在现代基于虚拟内存管理（MMU）的操作系统上，所有的内存访问都必须经过 MMU 和页表。

稍微回顾一下这个流程，因为它是理解问题的关键。当软件（进程或内核）试图访问一个地址时，并不是直接把地址甩到物理总线上。以下是一段典型的「寻路」过程：

CPU 缓存检查：首先看这个虚拟地址对应的数据是不是已经在 CPU 的 L1/L2 缓存里了。如果在，皆大欢喜；如果不在，这就是一次昂贵的 LLC Miss。
TLB 查找：如果缓存没命中，虚拟地址会被交给 MMU。MMU 先去查 TLB（页表缓存）。如果 TLB 里记录了虚拟地址到物理地址的映射，那就直接拿到物理地址；如果没找到，这就是一次昂贵的 TLB Miss。
页表遍历：如果 TLB 也没辙，MMU 就得老老实实去遍历页表。如果是用户空间访问，就查用户页表；如果是内核访问，就查内核页表。最终，它把虚拟地址翻译成物理地址。
上总线：这个物理地址终于被放到总线上了，真正的读写操作才发生。

（这个流程的具体顺序在不同架构上会有差异，比如 ARM 经常是先查 MMU 再查缓存，但逻辑是一致的。）

想象一下：在现代 OS 上，即使是普通的 RAM 都无法被软件直接物理访问，一切都是虚拟化的。那么，对于那些根本就不是 RAM 的硬件外设内存，情况就更复杂了。

如果这些外设内存连 RAM 都算不上，它们还在页表里吗？如果不在，我们怎么访问？如果不解决这个问题，驱动代码就只能对着空气发号施令。

解决方案——映射 I/O 内存与 I/O 端口

为了解决这个问题，现代处理器提供了两条路。这也是理解硬件驱动的分岔路口。

Memory-mapped I/O (MMIO)：把处理器地址空间的一部分区域「割让」给外设设备。也就是说，外设的寄存器被映射到了我们的内存地址空间里。
Port-mapped I/O (PMIO / PIO)：提供专门的汇编指令（和对应的机器码）来访问一个独立的 I/O 地址空间。这个空间和内存空间是分开的。

接下来我们会分别深入这两种技术。但在那之前，我们必须先学会一件事：礼貌地向内核申请许可。

向内核申请许可

先别急着动手操作，想一想：内核才是系统资源的总管。你想用 I/O 资源，必须先打报告。

这不仅仅是走过场。当你申请资源时，内核其实是在内部建立一些数据结构（比如 struct resource），用来记录哪块区域被哪个驱动占用了，防止冲突。

正规的 I/O 操作流程必须包含这三步：

Before I/O：申请内存或端口区域的使用权。
During I/O：执行实际的读写（使用 MMIO 或 PMIO）。
After I/O：把区域归还给内核。

为了实现这一套流程，内核提供了一系列 API，具体用哪一组取决于你走 MMIO 还是 PMIO 路线。

Method of access	Before performing any I/O	Perform the I/O	After performing the I/O
MMIO	`request_mem_region()`	(见下文 MMIO 章节)	`release_mem_region()`
PMIO	`request_region()`	(见下文 PMIO 章节)	`release_region()`

这些宏定义在 linux/ioport.h 头文件中。我们来看看它们的签名：

/* 申请和释放 MMIO 区域 */
struct resource *request_mem_region(resource_size_t start, unsigned long n, const char *name);
void release_mem_region(resource_size_t start, unsigned long n);

/* 申请和释放 PMIO 区域 */
struct resource *request_region(unsigned long start, unsigned long n, const char *name);
void release_region(unsigned long start, unsigned long n);

参数说明：

start：I/O 内存区域或端口的起始地址。
- 对于 MMIO，这是一个物理（或总线）地址。
- 对于 PMIO，这是一个端口号。
n：区域的长度（字节或端口数）。
name：你给这块区域起的名字，通常是驱动名。这个名字会出现在 /proc 文件系统里，方便调试。

返回值是 struct resource 指针。如果返回 NULL，说明申请失败（通常是因为已经被别的驱动占用了），这时候驱动通常会返回 -EBUSY。

好了，有了入场券，我们来看看怎么用。我们先从最主流的 MMIO 讲起。

理解并使用 Memory-Mapped I/O (MMIO)

在 MMIO 模式下，CPU 知道它的地址空间里有某些特殊区域是预留给外设的。你可以直接去查阅处理器或 SoC 的 datasheet，那张物理内存映射表上会写得清清楚楚。

为了让你有实感，我们来看一个真实的例子：树莓派。

树莓派使用的是 Broadcom 的 BCM2835（或后续型号）SoC。在官方文档 BCM2835 ARM Peripherals 的第 90 页，有一张物理内存映射图。其中 GPIO 寄存器组的映射情况如下：

（原文 Figure 3.1 的描述：显示了 GPIO 寄存器组的地址范围）

这里最关键的列是 Address。这是物理地址（或者说是总线地址），也就是 ARM 处理器物理地址空间里看到的 GPIO 寄存器位置。

起始地址：0x7e200000
长度：文档说有 41 个 32 位寄存器，所以长度大概是 41 * 4 = 164 字节。

⚠️ 注意树莓派的情况其实稍微复杂点，因为 BCM2835 有多个 MMU。有一个 VideoCore MMU 负责把 ARM 总线地址转换成 ARM 物理地址，然后才是常规的 ARM MMU 把物理地址转成虚拟地址。但原理上，它依然是一块映射在地址空间里的内存。

使用 `ioremap*()` API

正如我们在上一节提到的，你绝对不能直接去读写这些物理地址（0x7e2...）。正确的做法是告诉 Linux：把这些总线地址映射到内核的虚拟地址空间（VAS）里去。这样我们才能通过内核虚拟指针来访问它。

这就用到了 ioremap() API。

#include <asm/io.h>
void __iomem *ioremap(phys_addr_t offset, size_t size);

注意这个 API 的第一个参数：phys_addr_t。这是 Linux 驱动开发中少数几个需要你直接提供物理地址的场景之一（另一个是 DMA 操作）。

当你调用 ioremap() 时，内核会修改页表，在内核的 VAS 里划分出一块区域，建立起从「虚拟地址」到「硬件物理地址」的映射。

这就像 mmap() 系统调用把内核内存映射给用户空间一样，ioremap() 把外设 I/O 内存映射给了内核空间。

这个 API 返回一个 void * 类型的内核虚拟地址（KVA）。但这里有个奇怪的后缀 __iomem，构成了 void __iomem * 类型。

__iomem 只是一个编译器属性，编译完就没了。
它的存在是为了提醒人类开发者（以及静态分析工具）：这是一个 I/O 地址，不是普通的内存指针！千万别当普通指针用！

回到刚才树莓派 GPIO 的例子。如果我们想把那块 GPIO 寄存器映射到内核空间，代码大概是这样的：

#define GPIO_REG_BASE    0x7e200000  // 物理基地址
#define GPIO_REG_LEN     164         // 41 个寄存器 * 4 字节

static void __iomem *iobase;

/* 1. 先向内核申请这块区域的使用权 */
if (!request_mem_region(GPIO_REG_BASE, GPIO_REG_LEN, "mydriver")) {
    pr_warn("couldn't get region for MMIO, aborting\n");
    return -EBUSY;
}

/* 2. 建立映射 */
iobase = ioremap(GPIO_REG_BASE, GPIO_REG_LEN);
if (!iobase) {
    /* 映射失败处理... */
    release_mem_region(GPIO_REG_BASE, GPIO_REG_LEN);
    return -ENOMEM;
}

/* 3. 现在可以通过 iobase 进行 I/O 操作了... */

/* 4. 用完了，记得清理现场 */
iounmap(iobase);
release_mem_region(GPIO_REG_BASE, GPIO_REG_LEN);

这里的 iobase 就是一个内核虚拟地址（KVA）。它通常落在内核的 vmalloc 区域里。

下图展示了这个映射关系：

（原文 Figure 3.2 的描述：展示了 Physical I/O Peripherals 如何通过页表映射到 Kernel VAS 的 vmalloc 区域）

新生代——`devm_*` 托管 API

如果你写过现代 Linux 驱动，你会发现上面那种写法已经算是「老派」了。虽然很多老驱动还在用，而且理解它是基础，但现代驱动作者被期望使用更优雅的资源管理 API——也就是 devm_* 系列函数。

就像我们用 devm_kmalloc() 代替 kmalloc() 一样，devm_ioremap() 的好处在于：当驱动分离或设备卸载时，内核会自动帮你调用 iounmap()，完全不需要你操心。

它的签名如下：

void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,
                           resource_size_t size);

注意第一个参数是指向 struct device 的指针。在 platform 驱动的 probe 函数里，这个指针通常随手就有。

获取设备资源

现在问题来了：devm_ioremap() 的第二个参数 offset（也就是物理地址）从哪儿来？

总不能硬编码在驱动里吧？虽然以前（在 ARM 时代早期）大家就是这么干的，把 I/O 资源硬编码在板级文件里（arch/arm/mach-xxx）。但现在，尤其是 ARM 和嵌入式领域，大家用的是 Device Tree (设备树)。

设备树是一种用特定语言描述硬件拓扑的数据结构（.dts 文件）。它在内核编译时被二进制化（.dtb），由 Bootloader 传给内核。内核在启动时解析它，自动生成设备和资源信息。

驱动作者通常通过 platform_get_resource() API 来从这些数据结构里提取物理地址。

看一个真实的内核代码片段，来自三星 Exynos 4 SoC 的视频驱动 (drivers/gpu/drm/exynos/exynos_mixer.c)：

struct resource *res;

/* 从 platform 设备中获取 IORESOURCE_MEM 类型的资源 */
res = platform_get_resource(mixer_ctx->pdev, IORESOURCE_MEM, 0);
if (res == NULL) {
    dev_err(dev, "get memory resource failed.\n");
    return -ENXIO;
}

/* 获取到了物理地址，现在映射它 */
mixer_ctx->mixer_regs = devm_ioremap(dev, res->start, resource_size(res));
if (mixer_ctx->mixer_regs == NULL) {
    dev_err(dev, "register mapping failed.\n");
    return -ENXIO;
}

一站式服务：`devm_ioremap_resource()`

还有一个更懒、更常用的 API，叫 devm_ioremap_resource()。它做了三件事：

检查资源有效性。
调用 devm_request_mem_region() 请求内存。
调用 devm_ioremap() 建立映射。

这也太方便了，所以在 Linux 5.4 内核里它被调用了 1400 多次。签名如下：

void __iomem *devm_ioremap_resource(struct device *dev, const struct resource *res);

用法示例（来自树莓派随机数生成器驱动）：

static int bcm2835_rng_probe(struct platform_device *pdev)
{
    struct resource *r;

    /* 拿到资源结构体 */
    r = platform_get_resource(pdev, IORESOURCE_MEM, 0);

    /* 一步到位：检查、申请、映射 */
    priv->base = devm_ioremap_resource(dev, r);
    if (IS_ERR(priv->base))
        return PTR_ERR(priv->base);

    /* ... */
}

如果你在网上看到 devm_request_and_ioremap()，别慌，那是 2013 年前的老古董了，现在已经被 devm_ioremap_resource() 取代。

通过 `/proc/iomem` 查看映射

当你成功调用 request_mem_region() 后，可以在 /proc/iomem 这个伪文件里看到对应的条目。这需要 root 权限。

在 x86_64 虚拟机上：

$ sudo cat /proc/iomem
00000000-00000fff : Reserved
00001000-0009fbff : System RAM
...
00100000-3ffeffff : System RAM
18800000-194031d0 : Kernel code
...
fee00000-fee00fff : Local APIC

注意左边的列全是物理地址（或者总线地址）。你可以看到系统 RAM 在哪，Kernel 的代码段在物理内存的什么位置。

如果在树莓派上运行，你会看到不同的风格：

pi@raspberrypi:~ $ sudo cat /proc/iomem
00000000-3b3fffff : System RAM
...
3f200000-3f2000b3 : gpio@7e200000
3f201000-3f2011ff : serial@7e201000

注意到那个 gpio@7e200000 了吗？

左边的 3f200000... 是 ARM 总线地址。
右边的 @7e200000 是 ARM 物理地址。
这又是 BCM2835 那多层 MMU 带来的特殊视觉效果。

关于 /proc/iomem 的几个要点：

它显示的是当前被内核或驱动映射的 I/O 内存区域。
调用 request_mem_region() 时生成条目。
调用 release_mem_region() 时删除条目。

好了，地址映射好了，怎么真正读写这些数据呢？

MMIO —— 执行真正的 I/O

现在，外设的 I/O 内存已经映射到你的内核 VAS 里了。对你来说，它看起来就像一块普通的内存。

但千万别当普通内存用！

你不能直接用 *ptr = value 或者 val = *ptr 这种 C 语言常规操作去读写它。原因涉及内存屏障、缓存副作用、字节序等问题。内核提供了一套专门的封装 API。

执行 1 到 8 字节的读写

内核提供了针对不同位宽（8, 16, 32, 64 bit）的读写函数：

Read: ioread8(), ioread16(), ioread32(), ioread64()
Write: iowrite8(), iowrite16(), iowrite32(), iowrite64()

签名如下：

#include <linux/io.h>

u8 ioread8(const volatile void __iomem *addr);
u16 ioread16(const volatile void __iomem *addr);
u32 ioread32(const volatile void __iomem *addr);
/* ... ioread64 ... */

void iowrite8(u8 value, volatile void __iomem *addr);
void iowrite16(u16 value, volatile void __iomem *addr);
void iowrite32(u32 value, volatile void __iomem *addr);
/* ... iowrite64 ... */

这里的 addr 就是你从 ioremap() 那里拿回来的返回值，加上偏移量。

比如，要读一个 32 位寄存器（假设偏移是 0x10）：

u32 reg_value;
reg_value = ioread32(iobase + 0x10);

⚠️ 注意这些 I/O 例程是直接操作硬件的，所以它们本身不会失败（没有返回错误码的意思）。如果你的驱动不工作，那通常是地址错了、映射错了、或者偏移算错了，而不是 ioread32 函数本身报错。

一个常用的硬件自检技巧是「回环测试」：写一个值进去，再读回来。如果读到的一样，说明硬件连接和通路基本没问题。

执行重复（块）I/O 操作

如果你要读写几百个字节（比如 FIFO），用 for 循环包着 ioread8 也可以，但效率不高。内核提供了重复版本的 API，它们内部通常用了高度优化的汇编循环。

Read: ioread8_rep(), ioread16_rep(), ioread32_rep(), ioread64_rep()
Write: iowrite8_rep(), iowrite16_rep(), iowrite32_rep(), iowrite64_rep()

以 8 位重复读为例：

void ioread8_rep(const volatile void __iomem *addr, void *buffer, unsigned int count);

这会从 MMIO 地址 addr 连续读取 count 个字节，填入内核缓冲区 buffer。

类似地，重复写：

void iowrite8_rep(volatile void __iomem *addr, const void *buffer, unsigned int count);

`memset` 和 `memcpy` 变体

对于 MMIO，标准的 memset() 和 memcpy() 是不行的。必须用专门的 I/O 版本：

void memset_io(volatile void __iomem *addr, int value, size_t size);

void memcpy_fromio(void *buffer, const volatile void __iomem *addr, size_t size);
void memcpy_toio(volatile void __iomem *addr, const void *buffer, size_t size);

memset_io: 把 I/O 内存区域填充为某个值。
memcpy_fromio: 从硬件拷贝数据到内核内存。
memcpy_toio: 从内核内存拷贝数据到硬件。

补充说明：内核里还有一组很老的 API：readb(), readw(), readl(), readq() 和对应的 write...()。它们在功能上和 ioread... 类似，但现代驱动更推荐用 ioread... 系列。这里提到它们只是为了让你在阅读老代码（比如 2.6 时代的驱动）时不至于一脸懵逼。

理解并使用 Port-Mapped I/O (PMIO)

讲完了 MMIO，我们来看看那个「平行宇宙」——PMIO（也叫 PIO）。

在 PMIO 模式下，CPU 有独立的汇编指令（比如 x86 的 in / out）来读写 I/O 端口。这个 I/O 地址空间完全独立于内存地址空间。

在 x86 上，这个端口地址空间通常是 0x0000 到 0xffff（64 KB）。
不要把这里的「端口」和网络端口（TCP/UDP port）搞混了。这里的 I/O 端口本质上是硬件寄存器的另一种称呼。

虽然大多数现代处理器（包括 ARM）主要依赖 MMIO，但 x86 架构依然大量保留了 PMIO。比如键盘控制器 i8042、DMA 控制器、定时器、RTC 等古老而重要的设备，依然活在 I/O 端口空间里。

PMIO —— 执行真正的 I/O

相比 MMIO 的层层映射，PMIO 简单粗暴得多。因为 CPU 本身就有指令支持。

当然，礼貌还是要有的，依然要先调用 request_region() 和 release_region()。

读写 I/O 端口的 API 是：

Read: inb(), inw(), inl() (b=8bit, w=16bit, l=32bit)
Write: outb(), outw(), outl()

签名如下：

u8 inb(unsigned long addr);
u16 inw(unsigned long addr);
u32 inl(unsigned long addr);

void outb(u8 value, unsigned long addr);
void outw(u16 value, unsigned long addr);
void outl(u32 value, unsigned long addr);

这里的 addr 是端口号（比如 0x60），而不是内存地址。

PMIO 实例：`i8042` 键盘控制器

我们来看看经典的 i8042 驱动是怎么用 PMIO 的。

在驱动头文件 drivers/input/serio/i8042-io.h 里，定义了寄存器（端口）地址：

#define I8042_COMMAND_REG   0x64
#define I8042_STATUS_REG    0x64
#define I8042_DATA_REG      0x60

你可能会问：为什么 COMMAND_REG 和 STATUS_REG 地址一样？这是典型的硬件设计：读写同一端口，含义不同。读它是状态寄存器，写它是指令寄存器。

因为这些都是 8 位寄存器，所以驱动里全是用 inb 和 outb：

static inline int i8042_read_data(void)
{
    return inb(I8042_DATA_REG);
}

static inline void i8042_write_command(int val)
{
    outb(val, I8042_COMMAND_REG);
}

简单，直接。

通过 `/proc/ioports` 查看端口

就像 /proc/iomem 对应 MMIO 一样，内核提供了 /proc/ioports 来查看当前被占用的 I/O 端口。

在 x86_64 虚拟机上：

$ sudo cat /proc/ioports
0000-0cf7 : PCI Bus 0000:00
  0000-001f : dma1
  0040-0043 : timer0
  0060-0060 : keyboard
  0064-0064 : keyboard
  0070-0071 : rtc_cmos

可以看到，0x60 和 0x64 端口确实被标记为 keyboard 占用了。

如果你在树莓派（ARM）上跑这个命令，你通常看不到东西，或者很少，因为 ARM 设备基本都用 MMIO，不怎么用 I/O 端口。

PMIO 的几个补充点

String 指令（重复 I/O）：就像 MMIO 有 _rep 后缀一样，PMIO 也有对应的重复操作版本，叫做 ins 和 outs 系列。
```
void insb(unsigned long addr, void *buffer, unsigned int count);
void outsw(unsigned long addr, const void *buffer, unsigned int count);
/* ... insw, insl, outsb, outsw, outsl ... */
```
比如 insw 会从 I/O 端口 addr 读取 count 次（每次 2 字节）到缓冲区。
Paused I/O (_p 后缀)：还有一组 API 叫 inb_p(), outb_p() 等。这里的 _p 代表 pause（暂停）。在早期的慢速外设时代，这表示在两次 I/O 之间插入一小段延迟。但在现代内核里，这些通常只是简单的宏包装，实际上并没有真正的延迟功能，只是为了保持向后兼容。
用户空间的 PIO：你也可以在用户空间通过 iopl() 或 ioperm() 系统调用来获得 inb/outb 的权限。但这需要 root 权限（CAP_SYS_RAWIO）。这就允许你写一个用户空间的驱动。

本章回响

这一章我们走完了从「物理地址」到「虚拟地址」再到「实际读写」的完整链路。这是一切硬件操控的基础。

如果没有 MMU 和页表的映射，我们写的代码就像是站在玻璃墙外看着硬件，伸手却摸不着。通过 request_mem_region 和 ioremap，我们终于拿到了那把钥匙，打通了内核虚拟空间和硬件物理空间。

但我们也看到了世界并不总是统一的。MMIO 是现代的主流，它把硬件伪装成了内存；但 x86 的世界里还残留着 PMIO 的影子，那是一个独立的 I/O 空间，需要专门的 inb/outb 指令才能造访。理解了这两种机制，你才算真正看透了 Linux 硬件驱动的全貌。

目前为止，我们的驱动都是主动出击的——我们主动去读寄存器，主动去写配置。

但现实世界的硬件往往不是这样的。它不会乖乖等着被查，而是会在需要的时候主动向 CPU 发出信号：「我有数据了！」或者「出错了！」。

这就是下一章的主题——中断。在这个机制里，控制权将发生反转，不再是驱动查询硬件，而是硬件打断 CPU。这是通向高性能异步 I/O 的必经之路。

准备好了吗？下章见。

练习题

练习 1：application

题目：在编写一个网卡驱动时，你需要将设备寄存器的物理地址 0xFE000000 映射到内核虚拟地址空间以便访问。假设该寄存器区域大小为 4096 字节，且设备已正确申请了资源。请写出调用内核 API 将其映射并获取内核虚拟地址 vaddr 的核心代码语句。

答案与解析

答案：void __iomem *vaddr = ioremap(0xFE000000, 4096);

解析：在 Linux 内核中，访问 I/O 内存必须通过 ioremap() 将物理地址映射到内核虚拟地址空间。第一个参数是物理/总线地址 (phys_addr_t)，第二个参数是映射长度。返回值是 void __iomem * 类型的内核虚拟地址，该标记提示编译器和静态分析工具这是 I/O 内存而非普通 RAM。

练习 2：understanding

题目：在访问设备硬件寄存器时，为什么不能直接使用解引用操作符（如 *ptr = value;）或 memcpy() 对 ioremap 返回的地址进行读写，而必须使用 ioread32() / iowrite32() 等 I/O 专用 API？（请列举两个主要原因）

答案与解析

答案：1. 保证操作的原子性（避免字节合并在某些架构上导致错误）； 2. 处理内存屏障和顺序问题（确保 I/O 按顺序执行）； 3. 处理特定架构的字节序差异（如小端序 CPU 访问大端序设备）。

解析：普通内存访问会被编译器优化、重组，甚至合并，这在硬件 I/O 访问中是致命的，因为寄存器读写往往有副作用且要求严格的时序。iowrite 等 API 内部使用了内存屏障来防止 CPU 乱序执行，并保证操作是原子的（即一次性写入完整的 32 位），同时这些 API 抽象了底层硬件架构的差异，提高了驱动的可移植性。

练习 3：application

题目：假设你要编写一个 Platform 驱动，在 probe 函数中需要初始化设备的 I/O 内存。已知设备树中已定义了 reg 属性。请使用现代的 devm_* 托管 API 写出获取资源并进行映射的完整代码逻辑（假设设备结构体指针为 pdev，设备指针为 dev）。

答案与解析

答案：struct resource *res; void __iomem *base;

res = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!res) return -ENXIO;

base = devm_ioremap_resource(dev, res); if (IS_ERR(base)) return PTR_ERR(base);

解析：现代 Linux 驱动开发推荐使用 devm_* 托管 API，这样可以自动处理资源释放，避免驱动卸载时的内存泄漏。首先通过 platform_get_resource 从设备树获取 IORESOURCE_MEM 类型的资源结构体。然后使用 devm_ioremap_resource，它一步完成了 request_mem_region（申请资源）和 ioremap（建立映射）两个动作。如果出错，它返回 ERR_PTR，需要用 IS_ERR 检查。

练习 4：thinking

题目：在 ARM 架构的嵌入式系统开发中，设备手册显示某外设寄存器的物理地址是 0x3F201000。但在 Linux 内核中，驱动程序通常不是直接把这个地址硬编码给 ioremap，而是通过 Device Tree (DTS) 和 platform_get_resource 来获取。请从“软硬件解耦”和“内核通用性”的角度，分析为什么推荐这种做法？

答案与解析

答案：推荐做法是将硬件描述与驱动代码分离，由 Device Tree 负责描述硬件拓扑和地址，驱动只负责逻辑。理由：

代码可移植性：同一个外设可能在不同板子、不同 SoC 上的物理地址不同，使用 Device Tree 后，驱动代码无需修改即可适配不同硬件。
内核通用性：内核可以编译成一个通用的镜像，通过加载不同的 DTB 来适配不同的板卡，避免为每个板卡维护不同的内核分支。
模块化设计：符合 Linux 设备模型“驱动与设备分离”的设计哲学，便于硬件信息的统一管理。

解析：如果硬编码地址（如 #define PHY_ADDR 0x3F...），驱动就与特定板卡强耦合，一旦硬件地址变动（如芯片改版或走线变化），就必须修改并重新编译驱动代码。通过 Device Tree，物理地址成为了“数据”而非“代码”，Bootloader 可以根据具体运行的板卡加载对应的硬件描述文件，而 Linux 内核和驱动代码保持二进制级别的通用性。这是现代嵌入式 Linux 开发的标准范式。

要点提炼

内核驱动与硬件通信必须建立在严格的资源管理之上，开发者绝不能直接通过解引用物理地址指针来触碰硬件。正确的流程是先向内核申请 I/O 内存区域的占用权，防止多驱动冲突，随后通过 ioremap 机制建立物理地址到内核虚拟地址的安全映射。现代驱动开发推荐直接使用 devm_ioremap_resource 这一「一站式」API，它能自动完成资源检查、申请与映射，并在驱动卸载时自动处理释放，有效规避资源泄漏风险。

硬件寄存器并非普通内存，其读写操作具有副作用且对时序敏感，因此严禁使用标准的指针解引用或 memcpy。必须使用内核提供的专用 API（如 ioread32 和 iowrite32）来访问 I/O 内存，这些函数封装了内存屏障并阻止编译器优化，确保指令严格按照代码顺序执行且访问宽度严格匹配硬件规范。这种严格的接口隔离是保障硬件操作可靠性的基石。

Linux 内核支持两种截然不同的硬件访问模型：基于内存映射的 I/O（MMIO）和基于端口映射的 I/O（PMIO）。MMIO 将外设寄存器映射到 CPU 的物理内存空间，主要应用于 ARM 等嵌入式系统，通过 ioremap 后的虚拟指针进行访问；而 PMIO 则是 x86 架构的传统特性，拥有独立的 I/O 地址空间，必须通过专门的 in/out 汇编指令及其封装函数（如 inb/outb）进行操作，两者在底层机制和 API 使用上完全不同。

在处理大量数据传输时，为了提升效率并绕过函数调用开销，内核提供了针对 I/O 操作的批量读写 API。例如 ioread32_rep 和 iowrite8_rep 等重复读写函数，能够利用处理器的字符串指令特性，高效地完成 FIFO 缓冲区的数据搬运。这种机制相比简单的循环调用单次读写 API，能显著降低总线访问延迟，提升吞吐量。

内核通过 /proc/iomem 和 /proc/ioports 伪文件向开发者提供了窥探系统资源分配情况的窗口。通过查看这些文件，开发者可以验证驱动是否成功申请到了预期的硬件地址范围或端口，这是调试硬件驱动冲突、确认资源注册状态最直观的手段。理解这一视图有助于快速定位资源争用问题，确保驱动与硬件的正确连接。

理解直接访问的困境​

解决方案——映射 I/O 内存与 I/O 端口​

向内核申请许可​

理解并使用 Memory-Mapped I/O (MMIO)​

使用 ioremap*() API​

新生代——devm_* 托管 API​

获取设备资源​

一站式服务：devm_ioremap_resource()​

通过 /proc/iomem 查看映射​

MMIO —— 执行真正的 I/O​

执行 1 到 8 字节的读写​

执行重复（块）I/O 操作​

memset 和 memcpy 变体​

理解并使用 Port-Mapped I/O (PMIO)​

PMIO —— 执行真正的 I/O​

PMIO 实例：i8042 键盘控制器​

通过 /proc/ioports 查看端口​

PMIO 的几个补充点​

本章回响​

练习题​

练习 1：application​

练习 2：understanding​

练习 3：application​

练习 4：thinking​

要点提炼​

理解直接访问的困境

解决方案——映射 I/O 内存与 I/O 端口

向内核申请许可

理解并使用 Memory-Mapped I/O (MMIO)

使用 `ioremap*()` API

新生代——`devm_*` 托管 API

获取设备资源

一站式服务：`devm_ioremap_resource()`

通过 `/proc/iomem` 查看映射

MMIO —— 执行真正的 I/O

执行 1 到 8 字节的读写

执行重复（块）I/O 操作

`memset` 和 `memcpy` 变体

理解并使用 Port-Mapped I/O (PMIO)

PMIO —— 执行真正的 I/O

PMIO 实例：`i8042` 键盘控制器

通过 `/proc/ioports` 查看端口

PMIO 的几个补充点

本章回响

练习题

练习 1：application

练习 2：understanding

练习 3：application

练习 4：thinking

要点提炼