From: Deepak Kodihalli <dkodihal@linux.vnet.ibm.com>
To: Brad Bishop <bradleyb@fuzziesquirrel.com>,
James Feist <james.feist@linux.intel.com>,
"Thomaiyar,
Richard Marian" <richard.marian.thomaiyar@linux.intel.com>,
"Bhat, Sumanth" <sumanth.bhat@intel.com>
Cc: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: Processing PLDM FRU information with entity manager
Date: Tue, 19 May 2020 09:10:05 +0530 [thread overview]
Message-ID: <7d8ba039-377f-c567-6a3d-5a18c4789df2@linux.vnet.ibm.com> (raw)
Hi,
IBM systems have a requirement to consume FRU information sent down via
the host firmware and then relay that onto D-Bus (and then onto
Redfish). The host firmware will send down FRU information using PLDM.
We wanted to use entity manager to enable transforming the PLDM FRU data
to D-Bus properties that fall under D-Bus inventory interfaces such as
the xyz.openbmc_project.Inventory.Decorator.Asset interface. I have an
update to the PLDM design doc to capture this flow [1], and some D-Bus
interfaces [2] proposed on Gerrit. Would appreciate feedback on the
same. The high level idea is that the pldm daemon will host raw PLDM FRU
information on D-Bus, and via JSON configs, entity manager can convert
those to D-Bus inventory objects (which then can be found by bmcweb).
From an entity manager perspective, I had few questions :
- I see there is provision for persistence, but it looks like applying
the persisted information works only if "D-Bus probes" succeed. We have
a requirement to make the host-sent inventory information available even
when the host is powered off. Now if the host has sent this, then powers
off, and then BMC reboots, the BMC will no longer have the raw PLDM FRU
information on D-Bus and hence the entity manager probe on the same will
fail. Question is, can the probes be made optional when reading the
persisted config (system.json)?
- How are hierarchical relationships between FRUs supposed to be
represented? Is that based on D-Bus pathnames? Or making use of
something like the D-Bus Associations interface? Any thoughts on how
representing such parent-child relation can be achieved via entity
manager configs?
[1] https://gerrit.openbmc-project.xyz/#/c/openbmc/docs/+/32532/
[2]
https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-dbus-interfaces/+/32533/
Thanks,
Deepak
next reply other threads:[~2020-05-19 3:40 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-19 3:40 Deepak Kodihalli [this message]
2020-05-20 16:28 ` Processing PLDM FRU information with entity manager Brad Bishop
2020-05-20 16:56 ` James Feist
2020-05-20 17:35 ` Brad Bishop
2020-05-20 17:46 ` James Feist
2020-05-26 12:56 ` D-Bus interface to provide data to entity manager (was: Processing PLDM FRU information with entity manager) Deepak Kodihalli
2020-05-27 13:50 ` D-Bus interface to provide data to entity manager Thomaiyar, Richard Marian
2020-05-27 13:58 ` Deepak Kodihalli
2020-05-27 15:25 ` Thomaiyar, Richard Marian
2020-05-27 15:46 ` Deepak Kodihalli
2020-05-27 17:19 ` Thomaiyar, Richard Marian
2020-05-28 12:09 ` Patrick Williams
2020-05-28 12:03 ` D-Bus interface to provide data to entity manager (was: Processing PLDM FRU information with entity manager) Patrick Williams
2020-05-28 12:24 ` D-Bus interface to provide data to entity manager Deepak Kodihalli
2020-05-28 16:42 ` Thomaiyar, Richard Marian
2020-05-28 18:05 ` Patrick Williams
2020-05-28 18:31 ` James Feist
2020-05-29 5:11 ` Deepak Kodihalli
2020-05-29 5:09 ` Deepak Kodihalli
2020-05-29 7:17 ` Thomaiyar, Richard Marian
2020-05-29 7:31 ` Deepak Kodihalli
2020-05-29 9:03 ` Thomaiyar, Richard Marian
2020-05-29 10:19 ` Deepak Kodihalli
2020-05-29 10:30 ` Deepak Kodihalli
2020-05-29 10:33 ` Thomaiyar, Richard Marian
2020-05-28 15:43 ` D-Bus interface to provide data to entity manager (was: Processing PLDM FRU information with entity manager) Brad Bishop
2020-05-28 18:21 ` D-Bus interface to provide data to entity manager James Feist
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7d8ba039-377f-c567-6a3d-5a18c4789df2@linux.vnet.ibm.com \
--to=dkodihal@linux.vnet.ibm.com \
--cc=bradleyb@fuzziesquirrel.com \
--cc=james.feist@linux.intel.com \
--cc=openbmc@lists.ozlabs.org \
--cc=richard.marian.thomaiyar@linux.intel.com \
--cc=sumanth.bhat@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.