_DSD 设备属性使用规则¶
属性、属性集和属性子集¶
ACPI 5.1 中引入的 _DSD（设备特定数据）配置对象允许通过 ACPI 命名空间提供任何类型的设备配置数据。原则上，数据的格式可以是任意的，但它必须由驱动程序识别的 UUID 来标识，该驱动程序处理 _DSD 输出。但是，对于 _DSD，Linux 内核中的 ACPI 子系统会识别通用 UUID，该子系统会自动处理与其关联的数据包，并将这些数据作为“设备属性”提供给设备驱动程序。
设备属性是一个数据项，由一个字符串键和一个与之关联的值（特定类型）组成。
在 ACPI _DSD 上下文中，它是 _DSD 返回包中通用设备属性 UUID 之后的子包的元素，如 _DSD（设备特定数据）实施指南文档中名为“知名 _DSD UUID 和数据结构格式”子部分的“设备属性 UUID”部分中所指定 [1]。
它也可以被视为给定设备的设备属性 UUID 子包中 _DSD 可以返回的键和关联数据类型的定义。
属性集是适用于硬件实体（如设备）的属性的集合。在 ACPI _DSD 上下文中，它是可以在给定设备的设备属性 UUID 子包中返回的所有属性的集合。
属性子集是属性的嵌套集合。它们中的每一个都与一个附加键（名称）相关联，允许将子集作为一个整体引用（并被视为一个单独的实体）。属性子集的规范表示是通过 _DSD（设备特定数据）实施指南文档中名为“知名 _DSD UUID 和数据结构格式”子部分的“分层数据扩展 UUID”部分中指定的机制 [1]。
属性集可以是分层的。也就是说，一个属性集可以包含多个属性子集，每个子集都可以包含其自身的属性子集，依此类推。
属性集的一般有效性规则¶
有效的属性集必须遵循设备属性 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 环境中自动工作，而不管其内容如何。