两个驱动的故事
去年有两个客户，让我们来设计在他们正在使用的操作系统上增加支持一个新的IEEE 802.3卷45的PHY。一个客户是QNX的用户，另一个客户是一个VxWorks用户。这两个实时操作系统对网络接口的管理采用的不同的方法，这使得我们也需要采用不同的方法来实现。
本文主要不是为了讲IEEE 802.3的卷45，但是快速来查看和提供一些定义还是有帮助的，理解一些专业术语就不会有障碍。
IEEE 802.3卷22
物理层设备(PHY)是负责将媒体访问控制器(MAC，又名网络控制器)产生的包数据放进传输层(同轴电缆、双绞线、CAT-5 电缆、光纤电缆等)。IEEE 802.3卷22描述了这是如何工作的。这包含了用来访问PHY寄存器来配置PHY和反馈诸如链接状态的状态信息的媒体独立接口(MII)。更准确地说，这是管理数据I/O接口(MDIO)，虽然很多人也用MII和MDIO来互换描述之。
媒体独立接口(MII)允许32个物理曾设备(PHY)链接到MDIO，每个PHY提供一组标准的5 bit的地址空间的寄存器，最多32个寄存器。这对于一个10/100 Mbit/s的设备是足够了，但是随着PHY变得更加复杂，速度提升以及不同的媒体介质的出现，制造商需要更多的寄存器来进行配置和初始化，状态和错误报告以及微调和校准。
IEEE 802.3卷45
IEEE 802.3 第 45卷定义了一种新的寻址方案，它扩展了PHY寻址方案，如下所示：
- MDIO 上最多 32 个 PHY 设备（与卷22相同）
- 每个 PHY 设备可由 32 个 MDIO 可管理设备 (MMD) 组成，包括两个具体供应商的 MMD
- 每个 MMD 有一个 16 位地址空间，即多达 65536 个寄存器
- 如果存在标准的 卷 22 寄存器，则它们位于 MMD 0 中
首次引入时，都是假设MAC会与PHY对话都是正常的。然而，人们随后希望（相当合理地）将这些较新的第45卷引入的PHY连接到他们的标准（卷22）MAC，这将如何工作呢？
通过卷22的卷45寄存器
答案都提供在这儿了：卷22访问卷45寄存器
该机制采用了一个间接寄存器的访问方式，提案中有明确说明，这儿不再赘述。本质上，它是这样工作的：
- 卷22寄存器 13 用于：
- 确定正在处理哪些 MMD
- 定义正在执行的操作（读或写）
- 卷22寄存器 14 用于：
- 在 MMD 中设置卷 45 寄存器的地址
- 设置数据写入寄存器
- 获取从寄存器中读取的数据
那么关键点在哪儿呢？ 45 卷定义了标准寄存器和特性，但为 PHY 供应商实现自己的寄存器和操作提供了很大的自由度。 我想这是在提供他们的“增值”，因此客户会购买他们的 PHY 设备。从软件的角度来看，这是一种使名义上遵守标准的设备以非常非标准的方式运行并且难以支持的方法。
至关重要的是，卷45的PHY不必提供允许现有软件使用它的标准 22 寄存器集（寄存器 13 和 14 除外），尽管功能上有所减少。
现在我们可以回到一些细节。
QNX的PHY物理层设备管理
QNX 以太网驱动程序管理 MAC，但也：
- 确定 PHY 支持哪些媒体并将它们通告给网络堆栈
- 提供通过 MDIO 访问 PHY 寄存器的程序
- 管理 PHY 初始化、配置和状态报告
QNX MII 管理库为以太网驱动程序提供了帮助。 这提供了一个独立于设备的 API，用于执行一些标准操作，例如：
- 重置 PHY
- 设置 PHY 模式（自动协商模式或固定速度/双工）
- 启动链路自动协商
- 获取自动协商结果
- 获取链接状态（链接打开或关闭）
这避免了在每个以太网驱动程序中重复此功能。
VxWorks的PHY物理层设备管理
VxWorks 采用了不同的方法。 以太网驱动程序必须提供通过 MDIO 读取和写入 PHY 寄存器的方法。 但是，PHY 管理由独立的 PHY 驱动程序执行，该驱动程序：
- 将支持的媒体介质广播到网络堆栈
- 管理 PHY 初始化、配置和状态报告
- 设置 PHY 模式（10/100 Mbit/s 或 1000 Mbit/s）
- 启动链接自动协商
- 提供链接状态
对于许多 PHY 设备，通用 PHY 驱动程序足以让它们正确运行并将数据传入/传出 MAC。 通常，MAC 只需要知道 PHY 模式（设置时钟和数据路径）和链路状态（让网络堆栈知道何时可以发送数据）。
Marvell 和 Broadcom PHY 是明显的例外。 除了明确定义的卷 22 寄存器之外，它们通常需要特定于设备的驱动程序来执行复杂和专有的初始化步骤，并从非标准寄存器中获取状态信息。
对于卷45的实时操作系统支持
QNX 和 VxWorks 的最新版本增加了对管理卷45 PHY 的一些支持。QNX SDP 7.1 包括其 MII 管理库的 卷45 版本，该库使用 卷22 至 卷45 间接寄存器访问机制。这包括对少数45卷 PHY 的支持。 但是，我不得不从 MII 头文件中收集到这一点，因为文档没有解释这一点。
困难在于使用这个库来支持需要供应商特定初始化序列或通过供应商特定寄存器提供状态的新设备，或执行45卷定义之外的任何事情。标准 QNX 开发许可证不提供操作系统库的源代码，因此选项包括：
- 获取源许可证并自行更新 MII 库
- 获取黑莓咨询服务来做这件事
- 将PHY驱动支持放入MAC驱动
卷45的PHY 管理：一种数据驱动的方法
我们的 QNX 客户不想做上述任何事情。他们想要一个既可扩展又不涉及编写新代码来添加对其他设备的支持的解决方案。事实上，他们提出了一种数据驱动的方法，为 PHY 定义了以下属性：
- 设备 ID（寄存器 2 和 3）
- 寄存器（和访问顺序）以设置链接速度
- 要读取的寄存器（和访问序列）以获得链接速度
- 用于初始化设备的寄存器和值
将来添加对新设备的支持只需要在 PHY 属性表中添加一个新条目。
完成这项工作的关键是模拟可以由 QNX MII 管理库管理的卷 22 PHY，就像读取卷 22 PHY 一样。当 MII 管理库访问标准的卷22 PHY 寄存器时，我们的代码访问了必要的卷45 PHY 寄存器并将数据转换为返回给管理库的值。
时间会证明这种方法的可扩展性到底有多大，但我对结果相当满意。
这就是一个驱动
由于以下原因，VxWorks 解决方案完全不同：
- 内核和设备驱动程序源代码是以标准开发许可证的形式被提供
- VxWorks 有一个定义方法和职责的 PHY 驱动程序模型
- VxWorks 7 包括通过卷22 寄存器 13 和 14 对卷45 寄存器间接访问的支持
换句话说，我们所要做的就是编写一个新的 PHY 驱动程序，并且 VxWorks VxBus 驱动程序框架会负责让 MAC 驱动程序可以访问它。
这也造成了一个乏味的叙述：人为地写驱动。
奇怪的是 QNX 网络堆栈基于 NetBSD 网络堆栈，它确实具有 PHY 驱动程序的概念。 目前尚不清楚为什么它没有并入 QNX，但如果我有源码许可Licence，情况可能会有所不同。
