_DSD Guidance updated

Re: this previous post:

Guidance on using ACPI _DSD with Linux

Al Stone of Red Hat published an updated version of 3 documents giving guidance on using _DSD ACPI:

[RFC DSD v3 00/04] How to Use the ACPI _DSD Device Properties UUIDs

A copy of the ChangeLog is also attached so that you can see what the primary changes were for this second version.

https://github.com/ahs3/dsd/tree/master/documentation

https://github.com/ahs3/dsd/commit/7fbdce494b9b7b952e709e43b8dbbfd5cf8d4fcb
https://github.com/ahs3/dsd/commits/master

Click to access _DSD-device-properties-UUID.pdf

Click to access _DSD-hierarchical-data-extension-UUID-v1.pdf

Guidance on using ACPI _DSD with Linux

Al Stone of Red Hat submitted a 4-part patch to the Linux-ACPI list. Excerpt from comments from the first patch:

How to Use the ACPI _DSD Device Properties UUIDs

In the three documents that follow, we lay out a process for defining the use cases of device properties returned by the ACPI _DSD (Device Specific Data) object in Data Structures associated with the Device Properties UUID [0] and the Hierarchical Properties Extension UUID. The term “_DSD device properties” below refers to the data formats associated with those two UUIDs only.  All other UUIDs used with _DSD are outside the scope of what is described here. The goal of these documents is to: (1) make clear to OS vendors which of the use cases of _DSD device properties need to be supported; (2) be clear on what those use cases should mean to the OS; and, (3) have all OSs use the same definitions for those use cases. The first document describes basic context and essential terminology for the process of submitting a use case for the _DSD device properties to a central location so that it can be reviewed and tracked. The next document describes a database for storing the use cases of _DSD device properties that have been reviewed and agreed upon.  The idea is to make this database publicly available so that OS developers and firmware creators can easily see what is already defined, what is in use, and what is not defined. The final document provides a formal language for describing the use cases of _DSD device properties.  The goal is to make it relatively easy to define new use cases of the _DSD device properties, by stating clearly what those definitions must look like.  This also makes building automated tools easier, allowing us to keep the process simpler, permit validation of the content, assist with documentation, and perform basic record keeping. […]

See full post and the github project:

https://github.com/ahs3/dsd/tree/master/documentation
https://marc.info/?l=linux-acpi&m=146955102920815&w=2
https://marc.info/?l=linux-acpi&m=146955096920780&w=2
https://marc.info/?l=linux-acpi&m=146955089620763&w=2
https://marc.info/?l=linux-acpi&m=146955077420741&w=2
https://marc.info/?l=linux-acpi&m=146955067620727&w=2

Also, there’s a Python-based _DSD command line tool in the same DSD github project!

https://github.com/ahs3/dsd