Linux I2C 子系统全解：结构、机制与工程实战

前言

I2C（Inter-Integrated Circuit）作为嵌入式系统和各种电子产品中最常用的串行通信总线之一，在 Linux 内核中的地位极其重要。然而，Linux I2C 子系统的分层结构、对象模型、驱动编写与平台适配，常常让初学者和有经验的驱动工程师都感觉“玄而又玄”：

i2c-core 到底是什么？它是结构体还是框架代码？
i2c_adapter/i2c_client/i2c_driver 这三者的真正职责和关系是什么？
设备树、ACPI 如何描述和管理 I2C 设备？
用户空间如何安全、优雅地操作 I2C 设备？
为什么有些 I2C 设备驱动放在 drivers/i2c/chips，有些则在各自子系统？
适配器和外设驱动之间的数据流和调用栈到底长什么样？

本文将用“站在一线工程师视角”的方式，结合内核主线代码，系统剖析 Linux I2C 子系统的设计精髓，厘清常见痛点，助你真正吃透 I2C 驱动开发的门道。

在这里插入图片描述

一、I2C 子系统的整体分层架构

1.1 为什么要分层？

在内核设计里，“分层”几乎是所有复杂子系统必须采取的手段。一方面解耦硬件和上层协议，另一方面便于移植和扩展。I2C 子系统的分层非常经典，既和 PCI、USB 等总线有相通之处，也有其独特的地方。

1.2 四层结构一览

层级	主要职责	典型源码文件	关键结构体（接口）
用户空间接口层	向用户空间提供 `/dev/i2c-x` 访问接口	drivers/i2c/i2c-dev.c	struct file_operations
设备驱动层	各类 I2C 外设（如 EEPROM、Sensor）协议驱动	drivers/misc/eeprom/at24.c drivers/i2c/chips/*.c	struct i2c_driver struct i2c_client
适配器驱动层	适配各类 I2C 控制器（主控/硬件）	drivers/i2c/busses/i2c-xxx.c	struct i2c_adapter struct i2c_algorithm
I2C 核心层	管理适配器、设备、驱动的注册、匹配与调度	drivers/i2c/i2c-core-base.c drivers/i2c/i2c-core-of.c	struct i2c_adapter struct i2c_client struct i2c_driver struct bus_type（i2c_bus_type）

分层的本质是：每一层只关心本层的职责，通过清晰的接口与上下层交互，彼此低耦合、高内聚。

二、I2C 子系统核心对象和关系

2.1 三大核心结构体

struct i2c_adapter
代表 I2C 控制器（主机端），由适配器驱动（adapter driver）实现。例如 i.MX6/8、Designware、Synopsys 等硬件厂商的控制器驱动都会定义并注册自己的 adapter。
```
struct i2c_adapter {struct module *owner;unsigned int class;const struct i2c_algorithm *algo;void *algo_data;struct device dev;int nr; // 适配器编号// ... 省略其余成员
};
```

struct i2c_client
代表 I2C 总线上的从设备（外设）。每个外设在系统里注册为一个 i2c_client。

struct i2c_client {unsigned short addr;struct i2c_adapter *adapter;struct device dev;// ... 省略其余成员
};

struct i2c_driver
代表外设驱动程序，由驱动开发者实现。会指定可以支持哪些 i2c_client。

struct i2c_driver {int (*probe)(struct i2c_client *, const struct i2c_device_id *);int (*remove)(struct i2c_client *);const struct i2c_device_id *id_table;struct device_driver driver;// ... 省略其余成员
};

2.2 i2c-core 的角色

i2c-core 是整个 I2C 框架的“中枢神经”：
它管理着 adapter、client、driver 的注册与注销；在总线匹配到合适的 client-driver 对时，自动调用 probe/remove 等回调；它还定义和注册了 i2c_bus_type，将 I2C 适配器和设备纳入内核统一的设备模型（/sys/bus/i2c）。

易混淆点：

i2c-core 并不是结构体对象，而是一组实现适配器/设备/驱动管理与调度的代码集合。
i2c-core 定义的结构体（adapter、client、driver）都是面向外部的对象，i2c-core 本身则是幕后操盘手。

2.3 各对象的注册和生命周期

适配器注册：i2c_add_adapter() / 注销：i2c_del_adapter()
驱动注册：i2c_add_driver() / 注销：i2c_del_driver()
设备注册：通常由核心层自动创建设备（client），也可用 i2c_new_client_device() 手动注册

典型适配器注册片段（i2c-imx.c）

static int imx_i2c_probe(struct platform_device *pdev)
{// ... 硬件初始化、资源分配struct i2c_adapter *adap = &i2c_imx->adapter;adap->owner = THIS_MODULE;adap->algo = &imx_i2c_algo;// ...i2c_add_adapter(adap); // 注册到 i2c-core// ...
}

典型设备驱动注册片段（at24.c）

static struct i2c_driver at24_driver = {.driver = {.name = "at24",.of_match_table = at24_of_match,},.probe_new = at24_probe,.remove = at24_remove,.id_table = at24_ids,
};static int __init at24_init(void)
{return i2c_add_driver(&at24_driver); // 注册到 i2c-core
}
module_init(at24_init);

三、I2C 设备树/ACPI与自动识别

3.1 设备树下的 I2C 设备描述

现代 SoC 平台上，I2C 设备和控制器大多通过 device tree 描述。例如：

&i2c1 {status = "okay";clock-frequency = <100000>;sensor@48 {compatible = "ti,tmp102";reg = <0x48>;};
};

&i2c1：引用已声明的 i2c1 适配器
sensor@48：代表挂在 i2c1 上、地址为 0x48 的设备
compatible：决定使用哪个驱动
reg：I2C 地址

i2c-core 会在启动时扫描各 bus 下的节点，根据 compatible 字符串自动和 i2c_driver 的 of_match_table 匹配，自动创建设备并调用 probe。

3.2 ACPI 下的 I2C 设备识别

X86/服务器平台常用 ACPI 描述 I2C 设备，匹配原理与 DT 类似，匹配 driver 的 acpi_match_table。

四、数据流与调用流程解析

4.1 从用户空间到硬件的数据流

用户空间调用 open/read/write/ioctl 操作 /dev/i2c-x
内核 i2c-dev.c 通过 file_operations 调用 i2c-core 的消息传输接口
i2c-core 调用 i2c_adapter 提供的 master_xfer/algo 方法
适配器驱动操作硬件控制器，完成 I2C 物理通信

真实代码流程片段（i2c-dev.c）：

static ssize_t i2cdev_write(struct file *file, const char __user *buf,size_t count, loff_t *offset)
{struct i2c_client *client = file->private_data;struct i2c_adapter *adap = client->adapter;// ...ret = i2c_transfer(adap, msgs, num);// ...
}

i2c_transfer 又会调用适配器驱动里定义的 algorithm（如 master_xfer）：

int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
{return adap->algo->master_xfer(adap, msgs, num);
}

五、工程痛点与常见疑问

5.1 i2c-core 到底是结构体还是代码？

答：i2c-core 不是结构体，是整个 I2C 子系统的核心实现代码模块，提供对象注册/调度/统一接口。它通过 struct bus_type 将 I2C 融入内核设备模型。

5.2 适配器驱动和设备驱动的关系到底怎么理解？

适配器驱动负责让“硬件能动起来”，对上暴露 i2c_adapter 对象，提供收发能力。
设备驱动（如 at24、tmp102）不直接操作硬件，而是通过 i2c-core 提供的抽象接口，调用 i2c_transfer 等 API 间接与硬件通信。
两者通过 i2c-core 桥接，对彼此无感知、相互独立，极大增强了代码复用和平台兼容性。

5.3 “I2C 总线”在内核里到底有没有独立的 struct？

I2C 总线没有像 PCI/USB 那样单独的 struct i2c_bus。Linux 用 adapter（控制器）+ client（设备）+ bus_type（总线类型）三者结合，实现了虚拟总线模型。所有挂在同一个 adapter 下的设备，即被认为挂在同一条逻辑 I2C 总线。

5.4 为什么 I2C 设备驱动分散在 chips、misc、media 等目录？

这是历史和分层带来的必然产物。芯片类通用驱动（如 EEPROM、RTC、温度传感器）有的放在 i2c/chips，有的归属于自己子系统（如摄像头 sensor、音频 codec 等），但它们的入口都是统一的 i2c_driver/i2c_client，只是组织目录不同。

5.5 设备树下 I2C 设备无法自动 probe 的常见坑

compatible 属性写错或驱动里未配置 of_match_table
i2c_adapter 未正常注册（如 status = “disabled”）
I2C 地址（reg）冲突或写错
驱动的 id_table 未包含正确的名称

六、典型实战代码分析：at24 EEPROM 驱动

以主线 drivers/misc/eeprom/at24.c 为例，展示 i2c_driver 的专业实现范式。

核心结构注册：

static struct i2c_driver at24_driver = {.driver = {.name = "at24",.of_match_table = at24_of_match,},.probe_new = at24_probe,.remove = at24_remove,.id_table = at24_ids,
};module_i2c_driver(at24_driver);