专题文章：Linux内核链表与Pinctrl数据结构解析
目标： 深入解析Pinctrl子系统中，struct pinctrl如何通过内核链表，来组织和管理其多个struct pinctrl_state。
1. 问题背景：一个设备，多种引脚状态
一个复杂的设备，例如一个现代WiFi/蓝牙二合一模块，在不同的工作模式下，对引脚的要求是不同的。我们假设它有四种状态，并在设备树中进行了如下声明：
// 在wifi_bt.dts中
&wifi_bt {...pinctrl-names = "default", // (A) 高速数据传输状态"idle", // (B) 低功耗空闲状态"sleep", // (C) 深度睡眠状态"bt_sco"; // (D) 蓝牙语音通话状态pinctrl-0 = <&wifi_pins_default>;pinctrl-1 = <&wifi_pins_idle>;pinctrl-2 = <&wifi_pins_sleep>;pinctrl-3 = <&bt_sco_pins>;...
};
当内核解析这个设备时，它需要在内存中为wifi_bt设备建立一个数据结构，来清晰地管理这四种引脚状态(A, B, C, D)以及它们对应的具体配置。
2. 核心数据结构：pinctrl 与 pinctrl_state
内核使用两个核心结构体来完成这个管理任务：
struct pinctrl(总管):- 这是为
wifi_bt设备创建的一个总的Pinctrl信息管理器。 - 关键成员：
struct pinctrl {// (P) ... 其他成员 ...// (Q) 一个链表头，是所有状态的“集合点”struct list_head states; // ... 其他成员 ... };
- 这是为
struct pinctrl_state(具体状态):- 每一种引脚状态（如"default"、“idle”）都对应一个这样的结构体实例。
- 关键成员：
struct pinctrl_state {// (R) 状态的名字const char *name;// (S) 一个链表头，用于存放此状态下的具体配置指令struct list_head settings; // (T) 一个链表节点，是把自己“挂”到总管链表上的“钩子”struct list_head node; };
3. 组织方式：嵌入式链表
Linux内核不把struct pinctrl_state本身直接串起来，而是通过它们内部的node成员（T）来建立连接。struct pinctrl里的states成员（Q）就是这个链表的“头结点”或“锚点”。
可视化数据结构关系：
(wifi_bt设备的总管: struct pinctrl)
+--------------------------------------------+
| (P) ... |
| (Q) states: [ next ]---------------------->| (指向A的node)
| ... |
+--------------------------------------------+^| (D的node指向Q，形成闭环)|
+---------------------------------------------------------------------------------------------+
| |
| (A) pinct-state "default" (B) pinct-state "idle" (C) pinct-state "sleep" (D) pinct-state "bt_sco" |
| +------------------------+ +------------------------+ +------------------------+ +------------------------+ |
| | (R) name="default" | | (R) name="idle" | | (R) name="sleep" | | (R) name="bt_sco" | |
| | (S) settings: [ ... ] | | (S) settings: [ ... ] | | (S) settings: [ ... ] | | (S) settings: [ ... ] | |
| | (T) node: [ next ]---->|-->| (T) node: [ next ]---->|-->| (T) node: [ next ]---->|-->| (T) node: [ next ]-----|
| +------------------------+ +------------------------+ +------------------------+ +------------------------+ |
| |
+---------------------------------------------------------------------------------------------+关系解读：
pinctrl->states(Q) 是链表的起点和终点，它形成了一个环。- 它不直接指向
pinctrl_state结构体(A, B, C, D)的开头。 - 它指向的是下一个元素的
node成员(T)。比如，从(Q)出发，可以找到(A)的node成员。从(A)的node成员，可以找到(B)的node成员，以此类推，最后(D)的node成员会指回(Q)，形成闭环。
4. 核心操作：如何通过node找到state
这是理解的关键。当内核需要查找名为"idle"的状态时，它会遍历这个由node成员组成的链表。
- 遍历： 内核代码会从
pinctrl->states(Q)开始，沿着next指针逐个访问(A)、(B)、©、(D)的node成员(T)。 - 获取
node指针： 在遍历过程中，比如当它访问到(B)的node成员时，它得到一个指向struct list_head的指针，我们称之为node_ptr。 - 反向计算 (使用
list_entry宏)：- 已知信息：
node_ptr：node成员在内存中的确切地址。struct pinctrl_state：node成员所在的外部大结构体的类型。node：node成员在struct pinctrl_state这个类型定义中的名字。
- 计算逻辑： 整个结构体的起始地址 = 成员的地址 - 成员在结构体内的偏移量。
- 内核的实现：
list_entry(node_ptr, struct pinctrl_state, node)这个宏会执行上述计算，并返回一个指向struct pinctrl_state的指针。在这个例子中，它会返回(B)这个pinctrl_state结构体的起始地址。
- 已知信息：
- 比较与返回： 内核拿到
pinctrl_state的指针后，就可以访问它的name成员®，与目标字符串"idle"进行比较。如果匹配，查找成功。
5. 结论
pinctrl_state中的node成员(T)，是该状态实例能够被链表管理的**“连接件”**。pinctrl中的states成员(Q)，是所有状态实例的**“组织者”**和链表的入口。- 内核通过遍历由
node组成的链表，并利用list_entry宏进行地址反向计算，来高效地查找和访问任何一个具体的pinctrl_state实例。这种“侵入式”设计是Linux内核中一种通用且高效的数据组织模式。
