| commit | df55704398ec8fc3cc608206f05a2226f134c786 | [log] [tgz] |
|---|---|---|
| author | Brad Bishop <bradleyb@fuzziesquirrel.com> | Mon Oct 04 15:51:11 2021 -0400 |
| committer | Patrick Williams <patrick@stwcx.xyz> | Fri Oct 22 21:46:31 2021 +0000 |
| tree | 97c098ffa5df9b255836118a77b06693993fe313 | |
| parent | 7fd1de390723586dd94bd0b0119f8273d20ff46e [diff] |
pcieslot, cpu: add upstream_processor association Define a mechanism for documenting associations in PDI YAML files. A new associations member is added to the interface definitions. The new associations member is an array, with each array element having an object or structure type that consists of a name, reverse_name (all OpenBMC associations are bi-directional), description, and an array of required_endpoint_interfaces. The name and reverse_name properties must be snake_case and comply with D-Bus specification restrictions on object paths so they could be used directly as an object path element in a real D-Bus implementation. Similarly the required_endpoint_interfaces array elements must also comply with D-Bus specification restrictions and best practices on interfaces names. Associations should only exist as subordinate objects to a superior object with a specific D-Bus interface - for example the upstream_processor association should only exist on objects which implement the PCIeSlot interface. This is the motivating thought behind documenting OpenBMC associations in the existing interface definition files instead of somewhere else. Reuse of upstream_processor in other interfaces is allowed (for example a memory DIMM), but it must be explicitly listed in each interface definition that wishes to host the association. This first use of the associations documentation adds an upstream_processor interface used to link PCIeSlots to upstream PCIe host bridges or on-processor PCIe root complexes. Change-Id: I1d8bdb90a2705c4f16c5b015b7135870782ad672 Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
YAML descriptors of standard D-Bus interfaces. The format is described by the sdbusplus binding generation tool sdbus++.
This project can be built with meson. The typical meson workflow is: meson builddir && ninja -C builddir.
The meson files used to handle the YAML files are automatically generated and found under the gen subdirectory. When adding or removing YAML files, this must be regenerated. This can be done with the helper script found in the gen subdirectory: cd gen && ./regenerate-meson.
Only the xyz/openbmc_project interfaces are built by default. Other interfaces can be enabled by meson options:
-Ddata_com_ibm=true-Ddata_org_open_power=trueExample: meson builddir -Ddata_com_ibm=true && ninja -C builddir