1. WiFi 技术概览：从 802.11 到 WiFi 7
做 WiFi 驱动开发，第一件事不是翻芯片手册，而是搞清楚你手里的无线芯片到底在跟什么标准打交道。802.11 协议族从 1997 年诞生到现在，已经迭代了快三十年。我见过不少工程师拿着 WiFi 6 的模组，却还在用 WiFi 4 的配置思路调参数——结果性能死活上不去。
这一节，我们先把 WiFi 技术的底牌翻一遍。你不需要背下所有协议细节，但得知道每个阶段解决了什么问题、带来了什么坑。
1.1 802.11 协议族演进：从 11Mbps 到 46Gbps
802.11 协议族的发展史，说白了就是一场「提速 + 抗干扰」的军备竞赛。我把它分成四个阶段：
| 协议版本 | 推出年份 | 频段 | 理论峰值速率 | 核心改进 |
|---|---|---|---|---|
| 802.11-1997 | 1997 | 2.4 GHz | 2 Mbps | 初代标准，FHSS/DSSS |
| 802.11b | 1999 | 2.4 GHz | 11 Mbps | HR-DSSS，真正商用化 |
| 802.11a | 1999 | 5 GHz | 54 Mbps | OFDM 引入，速率飞跃 |
| 802.11g | 2003 | 2.4 GHz | 54 Mbps | OFDM 下放 2.4G，兼容 b |
| 802.11n (WiFi 4) | 2009 | 2.4/5 GHz | 600 Mbps | MIMO + 40MHz 信道 |
| 802.11ac (WiFi 5) | 2013 | 5 GHz | 6.9 Gbps | MU-MIMO + 160MHz |
| 802.11ax (WiFi 6/6E) | 2019 | 2.4/5/6 GHz | 9.6 Gbps | OFDMA + 1024QAM |
| 802.11be (WiFi 7) | 2024 | 2.4/5/6 GHz | 46 Gbps | 320MHz + 4096QAM + MLO |
struct wiphy 里注册了哪些 iftype 和 supported_rates。这比看任何宣传资料都实在——硬件到底支持到什么程度，驱动代码不会骗人。
1.2 WiFi 4/5/6/7 核心差异：驱动开发者该关注什么
很多教程喜欢列一堆「OFDM vs OFDMA」「MU-MIMO vs SU-MIMO」的对比表。但作为驱动开发者，我更关心这些技术差异会怎么影响我的代码。
WiFi 4 (802.11n) —— MIMO 的起点
WiFi 4 最大的贡献是引入了 MIMO。这意味着驱动里第一次需要处理多个天线路径的同步问题。我记得早期调试一个 2x2 MIMO 的网卡时，发现两根天线收到的信号相位差总是对不上——后来查出来是 PCB 走线长度没做等长补偿。嗯，硬件问题，但驱动也得背锅，因为驱动没做信道校正。
- 信道宽度：20/40 MHz，驱动要处理 HT20/HT40 切换
- 调制方式：最高 64QAM，5/6 编码率
- 空间流：最多 4 条，但消费级产品通常 2 条
- 驱动关注点：天线映射、A-MPDU 聚合、HT Capabilities IE 解析
WiFi 5 (802.11ac) —— 5 GHz 的爆发
WiFi 5 放弃了 2.4 GHz，专注 5 GHz。这给驱动带来的最大变化是：信道宽度从 40 MHz 跳到了 80/160 MHz。信道越宽，干扰越敏感。我曾经在调试一个 160 MHz 场景时，发现 AP 和 STA 的 DFS 信道检测结果总是不一致——最后定位到是驱动里的 CAC 定时器精度不够，导致信道切换时机错位。
- 信道宽度：80/160 MHz，VHT 模式
- 调制方式：256QAM，5/6 编码率
- 关键特性：MU-MIMO（下行），波束成形
- 驱动关注点：VHT Capabilities、BF 反馈矩阵、MU 分组调度
WiFi 6 (802.11ax) —— OFDMA 时代
WiFi 6 是真正让驱动开发变得复杂的一代。OFDMA 把信道切成了资源单元（RU），驱动需要管理的不再是「谁在发」，而是「谁在用哪个 RU 发」。我刚开始接触 OFDMA 调度时，总觉得这跟 LTE 的调度器差不多——后来发现完全不是一回事。WiFi 的 OFDMA 是竞争和调度混合的，驱动得同时处理 EDCA 和 Trigger Frame。
- 信道宽度：20/40/80/160 MHz，支持 2.4/5/6 GHz
- 调制方式：1024QAM，最高 5/6 编码率
- 关键特性：OFDMA（上下行）、TWT、BSS Coloring
- 驱动关注点：RU 分配、Trigger Frame 生成、TWT 协商、空间复用参数
SU Beamformer 位。结果 AP 端一直发不出波束成形探测帧，导致下行速率只有正常值的 1/3。查了两天才发现是 Capabilities 位没置对——驱动里一个 bit 的错误，性能直接腰斩。
WiFi 7 (802.11be) —— 极致吞吐
WiFi 7 还没大规模铺开，但驱动开发已经要提前准备了。320 MHz 信道、4096QAM、MLO（多链路操作）——这三个特性每一个都够驱动喝一壶的。尤其是 MLO，它要求驱动同时维护多条链路的连接状态，并且在链路间做负载均衡和快速切换。说实话，这已经有点接近 5G NR 的复杂度了。
- 信道宽度：最高 320 MHz，EHT 模式
- 调制方式：4096QAM，3/4 或 5/6 编码率
- 关键特性：MLO、Multi-RU、Puncturing、16 空间流
- 驱动关注点：多链路状态机、链路选择策略、Puncturing 位图解析
1.3 WiFi 驱动在系统中的位置
很多初学者会把 WiFi 驱动理解成「控制无线网卡的那段代码」。这个说法没错，但太笼统了。实际上，WiFi 驱动在 Linux 系统中处于一个非常特殊的位置——它横跨了硬件抽象、内核网络栈、用户态配置管理三个层面。
我习惯把 WiFi 驱动的层次结构画成下面这张图：
从这张图可以清楚看到，WiFi 驱动并不是一个孤立的模块。它通过 NL80211 协议与用户态的 wpa_supplicant 通信，通过 netdev 接口与内核网络栈交互，再往下还要通过 SDIO/PCIe/USB 等总线与硬件对话。
驱动开发者的核心战场：
- cfg80211 回调：实现
start_ap、connect、scan等操作 - mac80211 钩子：处理
tx、rx、sta_state等事件 - 硬件接口层：读写寄存器、收发固件命令、管理 DMA 描述符
- 中断与底半部：处理 TX/RX 完成、链路状态变化、错误恢复
举个例子，当用户执行 iw wlan0 scan 时，整个调用链是这样的：
iw通过 NL80211 发送NL80211_CMD_TRIGGER_SCAN到内核- cfg80211 验证权限后，调用驱动注册的
scan回调 - 驱动构造 Probe Request 帧，通过硬件接口发送到空口
- 硬件收到 Probe Response 后触发中断，驱动在中断处理中读取数据
- 驱动将扫描结果通过 cfg80211 上报，最终回到用户态
你看，一个简单的扫描操作，就涉及了用户态、内核子系统、驱动、硬件四个层面的协作。任何一个环节出问题，扫描都可能失败或者超时。
iw event 和 iw dev wlan0 scan dump 确认用户态和内核的交互是否正常。如果 NL80211 消息能正确下发但硬件没反应，那问题大概率在驱动和固件的接口上。如果连 NL80211 消息都发不下去，那就要检查 cfg80211 的注册和权限了。
最后说一句，WiFi 驱动开发的门槛不在于你背了多少协议标准，而在于你能不能把「802.11 协议」和「Linux 内核机制」这两条线拧在一起。后面的章节，我们会一条一条地拆开来看。