If I am understanding the question, what we are trying to document here are *only* those entries needed in the _DSD method, and specifically*only* for the device properties UUID [0]. All of the other methods -- _CRS, _STA, and so on -- should be used as described in the spec. So, no, I don't think we need to document in this forum the info from _CRS. It will be in the DSDT, and its use is well described in the spec. In the case of the devices properties UUID used by _DSD, however, we have to document it in a forum external to the spec, and external to the Linux kernel, since the spec does not provide such a mechanism, and we are trying to use the same property definitions across multiple OSs. Did I answer your question? Or did I answer a different question entirely:)?

Device (IPHY) { Name (_HID, "QCOM8071") Method (_CRS, 0x0, Serialized) { Name (RBUF, ResourceTemplate () { Memory32Fixed (ReadWrite, 0x410400, 0xc00) // Base address Memory32Fixed (ReadWrite, 0x410000, 0x400) // Per-lane digital Interrupt (ResourceConsumer, Edge, ActiveHigh, Exclusive, , , ) {0x11E} }) Return (RBUF) } }

On 09/23/2016 02:32 PM, Timur Tabi wrote: > > Al Stone wrote: > > > > If I am understanding the question, what we are trying to > > document here are > > *only*  those entries needed in the _DSD method, and > > specifically*only*  for > > the device properties UUID [0].  All of the other methods -- > > _CRS, _STA, and > > so on -- should be used as described in the spec. > > > > So, no, I don't think we need to document in this forum the info > > from _CRS.  It > > will be in the DSDT, and its use is well described in the > > spec.  In the case of > > the devices properties UUID used by _DSD, however, we have to > > document it in a > > forum external to the spec, and external to the Linux kernel, > > since the spec > > does not provide such a mechanism, and we are trying to use the > > same property > > definitions across multiple OSs. > > > > Did I answer your question?  Or did I answer a different question > > entirely:)? > Kinda.  Device tree documents everything in one place.  Where am I > supposed to > document the _CRS nodes? Ah.  I think I understand better. > > > > >     Device (IPHY) { > >         Name (_HID, "QCOM8071") > > > >         Method (_CRS, 0x0, Serialized) { > >             Name (RBUF, ResourceTemplate () { > >                 Memory32Fixed (ReadWrite, 0x410400, 0xc00) // > > Base address > >                 Memory32Fixed (ReadWrite, 0x410000, 0x400) // > > Per-lane digital > > > >                 Interrupt (ResourceConsumer, Edge, ActiveHigh, > > Exclusive, , , ) > >                     {0x11E} > >             }) > >             Return (RBUF) > >         } > >     } > > > The driver expects the first Memory32Fixed to be the base addres, > and the second > to be the per-lane address.  If we were to swap those two lines, > the driver > would crash.  Where do we document this requirement? > AFAIK, this will need to be documented in the driver itself, unless one of the macros listed in section 6.4 of the ACPI spec does what you need.  You might be able to use the vendor defined resource descriptor to distinguish the two items, for example, so it doesn't really matter what order they are stored in in the Package().  Still, that would need at least a comment in the driver code. This does raise an interesting point, though, that's probably well outside of this forum's scope.  I doubt this is the only place in the spec where the content of a Package() can be ambiguous; perhaps there needs to be some further meta information kept with the Package() or outside of the ACPI tables.  If you have ideas on how you might want to do that, let me know, and maybe we end up with a proposed spec change.

Hart, Darren wrote: > This is indeed a very good point - thank you for raising the question. > The DSD database is intended to provide documentation for system > firmware and OS developers to be able to develop software support for > the device - and it makes perfect sense for all of this information to > be kept together in one place. > > How do you currently inform your BIOS vendors of what they need to > provide in the full ACPI device object? Can this be linked to in the > property comments? We are the BIOS vendor :-). I just modify the ACPI tables directly and then I do git-push. Voila! Updated! AFAIK, there is no mechanism where my group documents any of the ACPI table data for the drivers we develop. Harb would know for sure, however.