_DSD 设备属性使用规则

属性、属性集和属性子集

ACPI 5.1 中引入的 _DSD (设备特定数据) 配置对象允许通过 ACPI 命名空间提供任何类型的设备配置数据。 原则上,数据的格式可以是任意的,但它必须由 UUID 标识,该 UUID 必须被处理 _DSD 输出的驱动程序识别。 但是,Linux 内核中的 ACPI 子系统识别的 _DSD 定义了通用 UUID,它会自动处理与它们关联的数据包,并将这些数据作为“设备属性”提供给设备驱动程序。

设备属性是一个数据项,由字符串键和与其关联的值(特定类型)组成。

在 ACPI _DSD 上下文中,它是通用设备属性 UUID 后的子包的一个元素,如 _DSD(设备特定数据)实施指南文档 [1]中标题为“众所周知的 _DSD UUID 和数据结构格式”子节“设备属性 UUID”部分中所指定。

它也可以被视为键的定义和关联的数据类型,_DSD 可以在给定设备的设备属性 UUID 子包中返回。

属性集是适用于硬件实体(如设备)的属性的集合。 在 ACPI _DSD 上下文中,它是可以在给定设备的设备属性 UUID 子包中返回的所有属性的集合。

属性子集是属性的嵌套集合。 它们中的每一个都与一个附加键(名称)相关联,允许将子集作为一个整体引用(并被视为一个单独的实体)。 属性子集的规范表示形式是通过 _DSD(设备特定数据)实施指南文档 [1]中标题为“众所周知的 _DSD UUID 和数据结构格式”子节“分层数据扩展 UUID”部分中指定的机制。

属性集可以是分层的。 也就是说,属性集可以包含多个属性子集,每个属性子集可以包含自己的属性子集,依此类推。

属性集的一般有效性规则

有效的属性集必须遵循设备属性 UUID 定义文档 [1] 给出的指导。

_DSD 属性旨在作为 ACPI 规范定义的现有机制的补充,而不是替代。 因此,作为规则,只有在 ACPI 规范没有直接规定处理底层用例的情况下才应使用它们。 从 _DSD 返回不遵循该规则的属性集(在与设备属性 UUID 关联的数据包中)通常是无效的。

其他注意事项

在某些情况下,即使原则上遵循了上面给出的一般规则,属性集仍然可能不被视为有效的属性集。

例如,这适用于可能导致内核代码(设备驱动程序或库/子系统)以可能导致与 ACPI 命名空间中的 AML 方法冲突的方式访问硬件的设备属性。 特别是,如果内核代码使用设备属性来操作通常由与电源管理相关的 ACPI 方法控制的硬件,例如 _PSx 和 _DSW(对于设备对象)或 _ON 和 _OFF(对于电源资源对象),或者由 ACPI 设备禁用/启用方法(例如 _DIS 和 _SRS)控制的硬件,则可能会发生这种情况。

在内核代码可能由于使用设备属性而导致 AML 混淆的所有情况下,所讨论的设备属性不适合 ACPI 环境,因此它们不能属于有效的属性集。

属性集和设备树绑定

通常,使 _DSD 返回遵循设备树绑定的属性集是有用的。

但是,在这些情况下,首先必须考虑上述有效性注意事项,并且必须避免从 _DSD 返回无效的属性集。 因此,可能无法使 _DSD 字面意思且完整地返回遵循给定 DT 绑定的属性集。 尽管如此,为了代码重用,以设备属性的形式提供尽可能多的配置数据并以适合手头用例的 ACPI 特定机制来补充它可能是有意义的。

无论如何,不应期望字面意思遵循 DT 绑定的属性集在 ACPI 环境中自动工作,无论其内容如何。

参考