_DSD 设备属性使用规则

属性、属性集和属性子集

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

设备属性是一个数据项，由一个字符串键和一个与之关联的值（特定类型）组成。

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

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

属性集是适用于硬件实体（如设备）的属性集合。在 ACPI _DSD 上下文中，它是可以在相关设备的设备属性 UUID 子包中返回的所有属性的集合。

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

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

属性集的一般有效性规则

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

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

其他注意事项

在某些情况下，即使原则上遵循上述一般规则，属性集仍可能不被视为有效属性集。

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

在所有情况下，内核代码可能会执行一些会因使用设备属性而混淆 AML 的操作，所讨论的设备属性不适用于 ACPI 环境，因此它们不能属于有效的属性集。

属性集和设备树绑定

让 _DSD 返回遵循设备树绑定的属性集通常很有用。

但是，在这些情况下，必须首先考虑上述有效性考虑，并且必须避免从 _DSD 返回无效的属性集。 因此，可能无法让 _DSD 返回完全遵循给定 DT 绑定的属性集。 不过，为了代码重用，以设备属性的形式提供尽可能多的配置数据，并使用适合当前用例的 ACPI 特定机制对其进行补充可能是有意义的。

无论如何，无论其内容如何，​​都不应期望遵循 DT 绑定的属性集在 ACPI 环境中自动工作。

参考

https://github.com/UEFI/DSD-Guide