The first submittal of DSD device properties has been a bit rocky. I really 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 bindings, that's 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. 2. If a device property defines something that should have been set by UEFI, 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. 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. Thanks. -- ciao, al ----------------------------------- Al Stone Software Engineer Red Hat, Inc. ahs3(a)redhat.com -----------------------------------