设备管理命名空间对象

ACPI 5.0 规范定义了可用于管理设备的多种命名空间对象。 例如，设备标识对象包含连接到总线的设备（例如 I2C）的标识信息，这些设备不支持子设备的硬件枚举。 其他类型的命名空间对象可以指定系统资源，描述设备依赖项，并指示哪些设备可以禁用。

Windows 中的设备标识

Windows 即插即用基于设备枚举器提供的设备标识符查找并加载设备驱动程序。 枚举器是知道如何从设备中提取标识信息的总线驱动程序。 某些总线（如 PCI、SD 和 USB）具有硬件定义的机制来执行此提取。 对于不支持这一特性的总线（如处理器总线或简单外围总线），ACPI 在命名空间中定义了标识对象。

Windows ACPI 驱动程序（Acpi.sys）将这些对象中找到的值组合到各种设备标识符字符串中，这些字符串可以专门或一般地标识设备，具体取决于驱动程序的需求。 为标识 ACPI 枚举设备而创建的一些字符串模式包括：

ACPI\VEN_vvv[v]&DEV_dddd&SUBSYS_sss[s]nnnn&REV_rrrr
ACPI\VEN_vvv[v]&DEV_dddd&SUBSYS_sss[s]nnnn
ACPI\VEN_vvv[v]&DEV_dddd&REV_rrrr
ACPI\VEN_vvv[v]&DEV_dddd
ACPI\vvv[v]dddd

可以通过打开设备管理器并检查已枚举的设备的 硬件 ID 和 兼容 ID 属性，来查看 Windows 为设备生成的标识符。 可以在 INF 文件中指定这些字符串，以识别要为设备加载的驱动程序。 INF 匹配的顺序是从最具体的硬件标识符（优先驱动程序）到最不具体的标识符（次要驱动程序），以便了解设备特定功能的驱动程序可以替换那些不太具体并因此仅支持部分设备功能的驱动程序。

设备标识符应仅用于 INF 匹配，并且不应由设备驱动程序分析或处理。 如果设备驱动程序需要识别它加载的特定硬件，建议的方法是在安装时让 INF 文件设置适当的注册表项。 然后，驱动程序可以在初始化期间访问这些密钥，以获取所需的信息。

ACPI 中的设备标识

硬件 ID （_HID）

在 ACPI 中标识设备的最低要求是硬件 ID （_HID） 对象。 _HID返回格式为“ABC[D]xxxx”的字符串，其中“ABC[D]”是标识设备制造商（“供应商 ID”）的 3 个字符或 4 个字符的字符串， xxxx 是标识该供应商制造的特定设备（“设备 ID”）的十六进制数字。 供应商 ID 在整个行业必须是唯一的。 Microsoft分配这些字符串以确保它们是唯一的。 可以从 即插即用 ID - PNPID 请求获取供应商 ID。

ACPI 5.0 还支持在 _HID 和其他标识对象中使用 PCI 分配的供应商 ID，因此你可能不需要从 Microsoft 获取供应商 ID。 有关硬件标识要求的详细信息，请参阅 ACPI 5.0 规范的第 6.1.5 节“_HID（硬件 ID）”。

兼容性 ID （_CID）

Microsoft已为与 Windows 附带的收件箱驱动程序兼容的设备保留供应商 ID“PNP”。 Windows 定义了许多设备 ID，以便与该供应商 ID 配合使用，可用于加载设备的 Windows 提供的驱动程序。 单独的对象（兼容 ID（_CID） 对象用于返回这些标识符。 Windows 始终首选硬件 ID（由 _HID 返回）而不是 INF 匹配和驱动程序选择中的兼容 ID（由 _CID 返回）。 如果供应商提供的特定于设备的驱动程序不可用，则此首选项允许将 Windows 提供的驱动程序视为默认驱动程序。 下表中的兼容 ID 是新建的，用于 SoC 平台。

子系统 ID（_SUB）、硬件修订（_HRV）和类别（_CLS）

ACPI 5.0 定义_SUB、_HRV和_CLS对象，这些对象可与_HID一起使用，以创建更唯一地标识设备的特定版本、集成或硬件修订的标识符，或指示 PCI 定义的设备类的成员身份。 这些对象通常是可选的，但 Windows 中的某些设备类可能需要这些对象。 有关这些对象的详细信息，请参阅 ACPI 5.0 规范的第 6.1 节“设备标识对象”。

为了可维护性，Windows 硬件认证工具包（HCK）要求 OEM 系统上的设备 ID 是“四部分”ID。 这四个部分包括供应商 ID、设备 ID、子系统供应商（OEM）ID 和子系统（OEM）设备 ID。 因此，OEM 平台需要子系统 ID （_SUB） 对象。

Device-Specific 方法（_DSM）

_DSM方法在 ACPI 5.0 规范的第 9.14.1 节“_DSM（设备特定方法）”中定义。 此方法提供单个特定于设备的数据和控制功能，这些函数可由设备驱动程序调用，而不会与其他此类特定于设备的方法冲突。 特定设备或设备类的_DSM定义了一个 UUID （GUID），该 UUID 保证不会与其他 UUID 冲突。 对于每个 UUID，_DSM方法可以实现的一组已定义函数来提供数据或执行驱动程序的控制函数。 特定于类的数据和数据格式以单独的设备类特定规范提供，并在 ACPI Device-Specific 方法中也进行了讨论。

地址（_ADR）和唯一 ID（_UID）

设备标识还有其他三项要求：

• 对于连接到可枚举硬件父总线（例如 SDIO、USB HSIC）但具有特定于平台的功能或控件（例如，侧带电源或唤醒中断）的设备，不使用_HID。 相反，设备标识符由父总线驱动程序创建（如前所述）。 但是，在这种情况下，地址对象（_ADR）需要位于设备的 ACPI 命名空间中。 此对象使操作系统能够将总线枚举设备与该设备的 ACPI 描述的功能或控件相关联。
• 在使用特定 IP 块的多个实例的平台上，由于每个块都有相同的设备标识对象，需要唯一标识符（_UID）对象来使操作系统区分这些块。
• 特定命名空间范围中的两台设备不能具有相同的名称。

设备配置对象

对于命名空间中标识的每个设备，设备消耗的系统资源（内存地址、中断等）也必须由当前资源设置（_CRS）对象报告。 支持报告多个可能的资源配置（_PRS），以及更改设备资源配置（_SRS）的控制，但可选。

SoC 平台的新功能包括设备可以使用的 GPIO 和简单的外围总线（SPB）资源。 有关详细信息，请参阅“常规用途 I/O”和“简单外围总线”（SPB）。

SoC 平台新增了一个通用固定的 DMA 描述符。 FixedDMA 描述符支持由许多系统设备共享 DMA 控制器硬件。 静态分配给特定系统设备的 DMA 资源（请求行和通道寄存器）列在 FixedDMA 描述符中。 有关详细信息，请参阅 ACPI 5.0 规范的第 19.5.49 节“FixedDMA （DMA 资源描述符宏）”。

设备状态更改

由于种种原因，ACPI 枚举的设备可以被禁用或删除。 提供了 Status （_STA） 对象，使此类状态更改能够与操作系统通信。 有关_STA的说明，请参阅 ACPI 5.0 规范的第 6.3.7 部分。 Windows 使用_STA来确定设备是否应被枚举、显示为已禁用或对用户不可见。 固件中的此控件对许多应用程序非常有用，包括停靠和 USB OTG 主机到功能模式切换。

此外，ACPI 还提供一种通知机制，ASL 可用于通知平台中驱动程序有关事件的变化，例如设备作为停靠的一部分被移除。 通常，当 ACPI 设备的状态发生更改时，固件必须执行“设备检查”或“总线检查”通知，使 Windows 重新枚举设备并重新评估其_STA。 有关 ACPI 通知的信息，请参阅 ACPI 5.0 规范的第 5.6.6 节“设备对象通知”。

启用/禁用

作为 Windows 即插即用的一部分，驱动程序必须能够由用户或系统动态启用和禁用（例如，用于更新驱动程序）。

On-SoC 设备集成到 SoC 芯片中，无法删除。 大多数 SoC 设备上的驱动程序可以免除启用和禁用的要求。 对于不享受豁免的驱动程序，有一些用于指示驱动程序支持有序移除的接口。 有关详细信息，请参阅 Microsoft Connect 网站上的标题为“减少 SoC 驱动程序的 PNP 要求”的文档。

如果驱动程序支持有序删除，并且可以禁用设备硬件（也就是说，可以将设备配置为停止访问其分配的资源），则设备的 ACPI 命名空间节点可以包括 Disable （_DIS） 对象。 每当删除驱动程序时，作系统都会评估此方法。 使用_DIS具有以下附加要求：

• 每当禁用设备时，_STA必须清除“已启用并解码其资源”位。
• 设备必须提供“设置资源设置”（_SRS）对象才能重新启用设备硬件，并在_STA中设置上述位。

有关详细信息，请参阅 ACPI 5.0 规范的第 6.2.3 节（_DIS）、6.2.15（_SRS）和 6.3.7（_STA）。

设备依赖项

通常，特定平台上的设备之间存在硬件依赖关系。 Windows 要求描述所有此类依赖项，以便它可以确保所有设备在系统动态变化时正常运行（设备电源已删除、驱动程序已停止和启动等）。 在 ACPI 中，按以下方式描述设备之间的依赖关系：

1. 命名空间层次结构。 作为子设备（在另一设备的命名空间中列为设备）的任何设备都依赖于父设备。 例如，USB HSIC 设备依赖于其连接的端口（父级）和控制器（上级）。 同样，系统内存管理单元（MMU）设备命名空间中列出的 GPU 设备依赖于 MMU 设备。

2. 资源连接。 连接到 GPIO 或 SPB 控制器的设备依赖于这些控制器。 在设备的 _CRS 中通过包含连接资源来描述这种类型的依赖项。

3. OpRegion 依赖项。 对于使用 OpRegions 执行 I/O 的 ASL 控制方法，操作系统不会隐式地知道依赖项，因为依赖项仅在控制方法评估期间确定。 此问题适用于即插即用驱动程序提供对区域的访问的 GeneralPurposeIO 和 GenericSerialBus OpRegions。 为了缓解此问题，ACPI 定义了 OpRegion Dependency （_DEP） 对象。 _DEP应在控件方法引用 OpRegion（HW 资源）的任何设备命名空间中使用，上述 1 或 2 均不适用于引用的 OpRegion 的连接资源。 有关详细信息，请参阅ACPI 5.0规范的第 6.5.8 节“_DEP（操作区域依赖项）”。

设备驱动程序之间也可能存在软件依赖关系。 还必须描述这些依赖项。

有关详细信息，请参阅以下资源：

• 有关驱动程序加载顺序依赖项，请参阅 指定驱动程序加载顺序。

• 有关电源关系依赖项，请参阅：

  • IoInvalidateDeviceRelations （若要触发建立电源关系，请调用 IoInvalidateDeviceRelations 例程，并使用 DEVICE_RELATION_TYPE 枚举值 PowerRelations。

  • IRP_MN_QUERY_DEVICE_RELATIONS

  • WdfDeviceInitSetPnpPowerEventCallbacks

  • 枚举总线上的设备

  • 动态枚举