On 10/4/2016 9:37 PM, Al Stone wrote:
The first submittal of DSD device properties has been a bit rocky. I
appreciate Austin and CodeAurora willing to be the first to try. Thank you.
What I see is that there is a difference of opinion on what device properties
are acceptable in _DSD. It seems we have a full spectrum of possibilities: on
one end is allowing almost anything the vendor wants, up to and including just
cloning DT bindings; on the other end is using a _DSD device property as almost
a last resort -- use it if and only if there is no other way to describe
something in ACPI that a device must have to function.
I don't see either extreme as practical. There will always be an exception, by
definition. Neither the kernel nor hardware technology are static.
The problem is, this difference of opinion now presents a stumbling block to
getting _DSD device properties registered.
So, let me suggest the following guidelines -- not rules, but guides -- that I
have been using when thinking about an acceptable use of _DSD device properties;
perhaps we can start from these to reach consensus:
1. If the set of device properties is a cut-and-paste from DT
not acceptable. If you need an ACPI driver, make one. Assuming the DT
driver can be re-used this way may be wrong, and may not be maintainable.
I would make the above the last one and sort of conditional. There are
simple cases in which the same set of properties will work for both DT
2. If a device property defines something that should have been set
don't take it. Initial frequencies and PHYs are a good example; the SBSA
and SBBR on arm64 defines such things.
3. If a device property duplicates an existing ACPI object or method, it's not
acceptable. Power management is handled quite well by D-states, so use them
instead of providing a table of frequencies for adjusting power usage. The
_CRS defines available registers; use that, not a device property.
4. Under no circumstances should a device property provide information that
can be retrieved from the hardware.
I like the above three.
I would add:
* _DSD properties should not provide a way for software to bypass
ACPI-defined mechanisms, like power management, or to manipulate
resources that according to the ACPI specification should be controlled
by the firmware or AML methods.
IOW, giving low-level access to anything that the other entities may
control is a no-no.
5. There are always exceptions; what is most practical?
This is where I start from. Do you have other guidelines? Are these too
restrictive? Too lax?
Let me know. I'd like to see if we can get to consensus. We've discussed
this briefly at the Linaro Connect firmware mini-conf, and we can of course
discuss it further at Linux Plumbers. But, let's come to some sort of an
agreement so that people can get their work done.