Thanks for doing this, Charles...
On 09/17/2015 06:34 AM, Charles Garcia-Tobin wrote:
Last week at the ASWG conference call I took the action of defining some
ground rules for _DSD submissions. I have drafted some up here. I¹d be
grateful to know your thoughts.
The following provides rules for the process of submitting _DSD
properties. This process must be followed by vendors wishing to see
drivers supported by OS vendors that support ACPI.
What properties can be described by _DSD
_DSD stands for device specific data, it is an object in ACPI that may be
stands for Device Specific Data. It is an object in ACPI that may be
associated with a device to describe specific device properties that
not covered by other mechanisms in the ACPI specification. An example may
be a mac address, or phy for an networking device.
s/mac/MAC/; s/phy/a PHY/
What properties must not be described by _DSD
_DSD must only be used to describe properties that are specific to a
device, rather than properties of the system as whole. i.e. Generic
properties that are required by generic kernel frameworks must not
described with _DSD.
_DSD must not be used to describe properties that are already covered in
the ACPI specification.
More specificity here would be good. Examples showing what is and is not
allowed would be very useful.
Using _DSD for things like clocks should be explicitly mentioned as not
at all allowed -- perhaps some cut'n'paste from the Linux kernel docs?
For a system described with ACPI, it must not a requirement that any
the following areas need and OS to evaluate _DSD in order to work:
s/and OS/an OS/
- Support dynamic device configurations (hot add/removal)
- Support hardware abstraction through control methods
- power management
- thermal management
- RAS interfaces
Stating a "why?" would be good here. I _think_ the implication is that
we're trying to avoid executing the ACPI interpreter at these times, but
stating that explicitly would be best.
_DSD must not be used to describe properties that are specific to an
operating system. For example properties with OS names in the key
would not allowed.
Submitting a binding
<Insert previous mails from Al Stone on the dsd too and dsd(a)acpica.org>
I've started collecting some of this documentation in a branch on github:
. There's a design-principles.txt
with Rafael's suggestions and our other commentary, and I'll put a draft
of this in there, too.
I think this section should be a separate document, as well as the bits below
Becoming a reviewer
Anybody who is member of the dsd(a)acpica.org can be a reviewer.
Becoming a maintainer
_DSD maintainership is a meritocracy. The process is:
1. You submit a request dsd(a)acpica.org to become maintainer
2. Existing maintainers take a view on teh merit of the request based
on the track record of the person making the request in:
2.1 OS verndors. Eg FreeBSD, RH, or Windows may propose a maintainer
vendors; e.g., FreeBSD, Red Hat or Microsoft may propose a maintainer
2.2 Existing FW representation technologies: ie person is a known
I think this should be s/ie/e.g.,/ -- correct?
ACPI contributor or Device Tree contributor or maintainer
IMHO, there needs to be a single final arbiter. Suppose there are some
number of maintainers, and they disagree on a submission. Someone will
need to make the final decision. If there is no final arbiter, there is
the risk of getting things stuck at some point, with no way to unstick
<< Other stuff to eventually include >>
Dsd tool stuff from Al, Rules on what properties look like from Rafael
Yup. See above.
-- 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
DSD mailing list
Linaro Enterprise Group