Hi all Sorry it¹s taken a while but here is second version of the DSD process and rules. Hopefully it has all the feedback incorporated. Thanks to those that reviewed it. There is also a TODO list that we need to get in place to get this going: TODO: 1. Fold these rules into dsd github from Al 2. Provide pointers to these rules in the ACPI documentation: http://www.uefi.org/sites/default/files/resources/_DSD-device-properti\ es-UUID.pdf In the same breath use this effort to fix the examples there to remove linux references 3. Provide pointers to these rules in kernel documentation (for all kernels that will support _DSD) 4. Retroactively apply the process to the few _DSD instances that have been created 5. Expand this process to add device specific _OSC Figured I¹d write this down so we know what we have left to do. Please add other things in there if you think I missed something out. I guess Al and I will take most of it on. Txt for process is below Cheers Charles Introduction ============ This document provides rules that apply to the to the usage of the Device Properties _DSD, which is covered by the following UUID: * daffd814-6eba-4d8c-8a91-bc9bbf4aa301 The Device Properties _DSD is described here: [1] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UU ID.pdf The rules should be followed by vendors wishing to see drivers that use the Device Properties _DSD supported by ACPI compliant OS vendors. What properties can be described by _DSD ======================================== _DSD stands for Device Specific Data. The Device Properties _DSD is an object in ACPI that may be associated with a device to provide the Operating System with information on the device and its configuration that cannot be represented in any other way, in accordance with the ACPI specification. It is regarded as invalid to use the information from _DSD instead of the existing ACPI mechanisms. Therefore _DSD may only be used in addition to existing ACPI mechanisms. An example may a MAC address, or PHY for a networking device. What properties must not be described by _DSD ============================================= As described in [1] the Device Properties _DSD must only be used to describe properties that are specific to a device, rather than properties of the system as whole. For this reason, the definition of each particular set of _DSD properties is only meaningful in association with a device ID. The interpretation of any _DSD properties that cannot be related to a specific device ID is essentially impossible in general and therefore it is invalid to use them. As described in [1] the Device Properties _DSD must not be used to provide the OSPM or drivers the same information that is provided by the _CRS object. Further, the existing interfaces provided to Operating Systems by the ACPI specification should still work, and not require additional parsing of _DSD objects, and therefore kernel changes, in order to operate correctly. Examples include: - Support dynamic device configurations (hot add/removal) - Support hardware abstraction through control methods - power management - thermal management - RAS interfaces By corollary the Device Properties _DSD should never be used to describe information that can be described by existing ACPI methodologies. For example: voltage regulators or clocks that may need to be turned on or off to manage the power of a device, should use existing power resource _ON/_OFF methods, or device _PSx methods, instead of _DSD. Submitting a binding ==================== <Insert previous mails from Al Stone on the dsd too and dsd(a)acpica.org&gt; Becoming a reviewer =================== Anybody who is member of the dsd(a)acpica.org can be a reviewer. Becoming a maintainer ===================== The process is for becoming a _DSD maintainer is as follows: 1. You submit a request dsd(a)acpica.org to become maintainer 2. Existing maintainers take a view on the merit of the request based on the track record of the person making the request in: 2.1 OS verndors. E.g. FreeBSD, RH, or Windows may propose a maintainer 2.2 Existing FW representation technologies: e.g. person is a known ACPI contributor or Device Tree contributor or maintainer -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782