commit | e4a64ba768a675937bcb41c5e74098c26de1d5e2 | [log] [tgz] |
---|---|---|
author | Thang Tran <thuutran@amperecomputing.com> | Fri May 16 13:13:36 2025 +0700 |
committer | Patrick Williams <patrick@stwcx.xyz> | Thu Oct 02 16:59:57 2025 +0000 |
tree | 6d6b6901e3315f8cf8d00adad0e422a0df3e8f23 | |
parent | bb86c6148f765fb0cf973679eae85990cba71693 [diff] |
Item: separate PCIe Function's properties into new interface Currently, the PCIeDevice interface describes properties for up to eight PCIe functions, but no association to individual PCIe functions is defined. To implement the Redfish Drive and NetworkInterface schemas, this change is necessary because those schemas associate with the specific PCIe function resources that produce them. This commit moves PCIe Function properties from PCIe Device to an independent PCIeFunction interface. The dbus object tree layout could be: ``` /xyz/openbmc_project/inventory/item/PCIeDevice0 | xyz.openbmc_project.Inventory.Item.PCIeDevice |---/xyz/openbmc_project/inventory/item/PCIeDevice0/PCIeFunction0 | xyz.openbmc_project.Inventory.Item.PCIeFunction |---/xyz/openbmc_project/inventory/item/PCIeDevice0/PCIeFunction1 | xyz.openbmc_project.Inventory.Item.PCIeFunction |---/xyz/openbmc_project/inventory/item/PCIeDevice0/PCIeFunction2 | xyz.openbmc_project.Inventory.Item.PCIeFunction ``` TODO: The PCIe function's properties in the PCIeDevice interface shall be removed when bmcweb [1] and peci-pcie [2] are updated. [1]: https://github.com/openbmc/bmcweb/blob/0fa3418803cb0af347903ae0b7d741f63d49cd32/redfish-core/lib/pcie.hpp#L628 [2]: https://github.com/openbmc/peci-pcie/blob/ec7361d5bce6be90effc2bed0adfea3df48f13d1/src/peci_pcie.cpp#L612 Change-Id: Ifba85d4ecb4847b737f1ace86bf8520ec31c0f03 Signed-off-by: Thang Tran <thuutran@amperecomputing.com>
YAML descriptors of standard D-Bus interfaces. The format is described by the sdbusplus binding generation tool sdbus++.
Before defining a new D-Bus interface or modifying an existing one, please read through the documented set of the common requirements and expectations.
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 and org/freedesktop interfaces are built by default. Other interfaces can be enabled by meson options:
-Ddata_com_ibm=true
-Ddata_org_open_power=true
Example: meson builddir -Ddata_com_ibm=true && ninja -C builddir