The DSD Rules doc has been stagnant for bit because of discussion and
concerns about wholesale-DT-import. Much of the language and proposed
rules are about addressing this concern. The main worry is that the
PRP0001 HID would allow using a DT style "compatible" string to bind a
driver. This in turn would make it easier for folk to import whole DTs,
which may duplicate and clash with existing ACPI functionality. The
"compatible" property also goes against the grain, in that instead of
being device and vendor specific, it is generic. In ARM we have been
discussing the PRP0001 ID method of binding drivers, and the rules of the
DSD rules doc and I wanted to summarise where we’ve got to. We now agree
that PRP0001 is needed, but we think there is some additional work
required to make this fly:
- UEFI.org will need to produce documentation describing the purpose of
the ID, and we’d be happy to work on the wording for that.
- To address the concern of wholesale-DT-import, we will need to come up
with a set of rules and guidelines on DT porting specifically. This is
something that we could host alongside the DSD rules doc perhaps. We will
be making some proposals here.
- The use of PRP0001 should be discouraged for entirely new devices, as
this is really more about porting existing drivers.
>From my own perspective, I’d be happy to drop the discussion on how to
phrase which ID methods are valid for an OS to use in driver binding. The
original language suggested by Rafael would works for me.
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.
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 their
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
associated with a device to describe specific device properties that are
not covered by other mechanisms in the ACPI specification. An example may
be a mac address, or phy for an networking device.
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 be
described with _DSD.
_DSD must not be used to describe properties that are already covered in
the ACPI specification.
For a system described with ACPI, it must not a requirement that any of
the following areas need and OS to evaluate _DSD in order to work:
- Support dynamic device configurations (hot add/removal)
- Support hardware abstraction through control methods
- power management
- thermal management
- RAS interfaces
_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>
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
2.2 Existing FW representation technologies: ie person is a known
ACPI contributor or Device Tree contributor or maintainer
<< Other stuff to eventually include >>
Dsd tool stuff from Al, Rules on what properties look like from Rafael
-- 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