驱动框架与Kconfig：驱动模块的Kconfig编写规范
说到Kconfig，很多刚入行的朋友觉得它就是个菜单配置文件。嗯，这么说也没错，但它的作用远不止于此。我个人习惯把Kconfig看作是驱动和内核之间的「契约」——你告诉内核你的驱动需要什么，内核根据这些信息决定要不要编译它。
说白了，Kconfig就是驱动模块的「自我介绍」。它告诉内核配置系统：我叫什么名字、依赖哪些子系统、需要哪些硬件资源、能不能被编译成模块。我见过太多驱动因为Kconfig写得马虎，导致编译时各种诡异的问题。
Kconfig的基本语法
先看一个最基础的例子。假设我们写了一个I2C温度传感器驱动，它的Kconfig条目长这样：
config SENSOR_TMP117
tristate "TMP117 temperature sensor support"
depends on I2C
help
Say Y here to support the TMP117 digital temperature sensor.
This driver can also be built as a module.
这里有几个关键点：
- config 后面跟的是配置宏的名字，最终会变成
CONFIG_SENSOR_TMP117 - tristate 表示三种状态：Y（编译进内核）、M（编译成模块）、N（不编译）
- depends on 是依赖声明，这里依赖I2C子系统
- help 是帮助信息，给用户看的
核心要点：tristate和bool的区别要搞清楚。bool只有Y/N两种选择，适用于那些不能作为模块的功能。比如内存管理相关的配置，你总不能把它编译成模块然后卸载掉吧？
依赖关系的正确写法
依赖关系是Kconfig里最容易出错的地方。我在项目中遇到过好几次因为依赖写错导致编译失败的情况。最常见的坑是「循环依赖」和「缺失依赖」。
来看一个稍微复杂点的例子：
config SENSOR_TMP117
tristate "TMP117 temperature sensor support"
depends on I2C
depends on THERMAL || !THERMAL
select REGMAP_I2C
help
TMP117 is a high-accuracy digital temperature sensor.
这里出现了两个新东西：
- depends on THERMAL || !THERMAL —— 表示无论THERMAL是否开启，这个驱动都可以编译。但如果有THERMAL子系统，驱动会利用它提供温度监控功能。
- select REGMAP_I2C —— 这是「反向依赖」。意思是当用户选中这个驱动时，内核会自动选中REGMAP_I2C。注意，select要慎用，它可能会破坏依赖链。
我曾经踩过的坑：有一次我写了一个SPI设备的驱动，用了select SPI。结果用户在内核里把SPI子系统整个关掉了，但我的驱动因为select强制打开了SPI。这导致编译时SPI核心代码缺失，报了一堆莫名其妙的错误。后来我改成depends on SPI，问题就解决了。
驱动与内核的配置绑定
配置绑定，说白了就是让驱动知道「我该在什么情况下被编译」。这不仅仅是Kconfig的事，还涉及到Makefile的配合。
看一个完整的例子：
# Kconfig
config SENSOR_TMP117
tristate "TMP117 temperature sensor support"
depends on I2C
help
TMP117 driver.
# Makefile
obj-$(CONFIG_SENSOR_TMP117) += tmp117.o
Makefile里的 obj-$(CONFIG_SENSOR_TMP117) 就是绑定点。当CONFIG_SENSOR_TMP117为Y时，tmp117.o会被编译进内核；为M时编译成模块；为N时完全不编译。
你想想看，如果Kconfig和Makefile不匹配会怎样？比如Kconfig里定义了配置项，但Makefile里没写对应的编译规则——那这个配置项就是个摆设，选了也没用。反过来，Makefile里引用了某个配置宏，但Kconfig里没定义——那编译时就会报未定义的错误。
多文件驱动的配置写法
有些驱动由多个源文件组成，这时候Makefile要稍微复杂一点：
# Kconfig
config SENSOR_TMP117
tristate "TMP117 temperature sensor support"
depends on I2C
help
TMP117 driver.
# Makefile
obj-$(CONFIG_SENSOR_TMP117) += tmp117.o
tmp117-objs := tmp117_core.o tmp117_i2c.o tmp117_sysfs.o
这里用 tmp117-objs 指定了多个目标文件。内核构建系统会自动把它们链接成一个tmp117.ko模块。我个人习惯把功能拆分成多个文件：核心逻辑放core文件，总线接口放i2c/spi文件，用户接口放sysfs文件。这样代码清晰，也方便维护。
Kconfig中的条件依赖
有时候依赖关系不是简单的「有或无」，而是需要根据条件来判断。比如：
config SENSOR_TMP117
tristate "TMP117 temperature sensor support"
depends on I2C
depends on THERMAL
depends on OF || ACPI
help
TMP117 driver.
这里 depends on OF || ACPI 表示驱动需要设备树（OF）或者ACPI来获取硬件信息。如果两个都没有，驱动就无法编译。为什么？因为TMP117需要知道它挂在哪条I2C总线上、地址是多少，这些信息要么从设备树拿，要么从ACPI拿。
我的建议：写Kconfig时，尽量把依赖写「松」一点。比如你的驱动支持设备树和ACPI两种方式，那就用OR条件。别一上来就depends on OF，把ACPI的用户拒之门外。我见过不少驱动因为依赖写得太死，导致在某些平台上无法使用。
Kconfig的层次结构
内核的配置菜单是有层级关系的。比如温度传感器驱动通常放在：
Device Drivers --->
[*] Industrial I/O support --->
[*] Temperature sensors --->
<M> TMP117 temperature sensor support
要实现这种层级，Kconfig文件要这样组织：
# drivers/iio/Kconfig
menu "Industrial I/O support"
source "drivers/iio/temperature/Kconfig"
endmenu
# drivers/iio/temperature/Kconfig
menu "Temperature sensors"
config SENSOR_TMP117
tristate "TMP117 temperature sensor support"
depends on I2C
endmenu
这里用 source 关键字引入了子目录的Kconfig文件。menu和endmenu定义了菜单的显示层级。嗯，要注意的是，menu本身不产生配置项，它只是用来组织界面的。
Kconfig编写规范总结
| 规范项 | 要求 | 说明 |
|---|---|---|
| 命名规范 | 全大写，下划线分隔 | 如 CONFIG_SENSOR_TMP117 |
| 类型选择 | 可模块化用tristate，否则用bool | 驱动通常用tristate |
| 依赖声明 | depends on 优先于 select | 避免强制依赖 |
| 帮助信息 | 必须包含功能描述 | 让用户知道这个驱动是干什么的 |
| Makefile匹配 | obj-$(CONFIG_xxx) 必须对应 | 否则配置项无效 |
记住：Kconfig写得好不好，直接决定了你的驱动能不能被用户方便地使用。我见过有些驱动把依赖写得极其复杂，用户想用还得先开一堆莫名其妙的配置项。好的Kconfig应该是「傻瓜式」的——用户只需要选中你的驱动，所有依赖自动满足。
Kconfig与驱动框架的交互流程
为了让你更直观地理解整个过程，我画了一张图：
这张图展示了从Kconfig配置到驱动最终运行的完整链路。你看，Kconfig在最上游，它决定了驱动要不要被编译。编译系统根据Kconfig生成配置宏，Makefile根据配置宏决定编译哪些文件。编译出来的内核模块在运行时，还需要和设备树或ACPI中的硬件描述进行匹配，才能正确绑定到硬件上。
任何一个环节出问题，驱动都跑不起来。我调试过不少「驱动加载失败」的问题，最后发现是Kconfig里的依赖写错了，导致驱动需要的某个子系统没被编译进去。嗯，这种问题最难排查，因为编译时不会报错，只有运行时才暴露。
避坑指南：写Kconfig时，建议先用 make menuconfig 看看你的配置项是否出现在正确的位置。然后用 make savedefconfig 生成精简的配置文件，检查依赖是否完整。我曾经因为少写了一个depends on，导致驱动在某个架构上编译不过，排查了整整一个下午。
好了，关于Kconfig的编写规范和驱动与内核的配置绑定，就讲到这里。记住一句话：Kconfig是驱动的「身份证」，写好了它，你的驱动才能被内核正确识别和编译。