From: James Feist <james.feist@linux.intel.com>
To: rgrs <rgrs@protonmail.com>
Cc: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
Alexander Amelkin <a.amelkin@yadro.com>,
"Thomaiyar,
Richard Marian" <richard.marian.thomaiyar@linux.intel.com>
Subject: Re: Faking Sensor Readings
Date: Thu, 12 Dec 2019 07:57:17 -0800 [thread overview]
Message-ID: <8cef3ef8-a275-2f36-dfeb-7b4da97c6f88@linux.intel.com> (raw)
In-Reply-To: <EPYcrss0WRTceNCXy6GM0cmf5GE-4TzTQLyLuYd581ufdbKteABRuQArHVWcPPAHaCBK8_0nIRJ2DP5hSh5jS2AgDPjr_snA5bh91FU-OOI=@protonmail.com>
On 12/11/19 9:28 PM, rgrs wrote:
> Hi James,
>
> Thanks for the help.
>
> One more clarification please,
>
> How is entity-manager different from phoshor-hwmon conf files?
>
Entity-manager does runtime detection based on available d-bus
properties. In most cases it's based on Fru Detection, but anything on
d-bus can be used to configure. So you can write Probe statements (at
the bottom of the configuration files in most cases) that say when this
key/value pair exists on d-bus, install this configuration. This is most
useful for add-in-cards or other removable devices, so that when it
exists, the configuration gets loaded. For example this retimer card
https://github.com/openbmc/entity-manager/blob/master/configurations/PCIE%20SSD%20Retimer.json
says when a Fru Exists with BOARD_PRODUCT_NAME set to a specific value,
then load these sensors. It can then export sensors to sysfs as well if
needed. Entity-manager is also not limited to sensors, it also
configures things like phosphor-pid-control
https://github.com/openbmc/entity-manager/blob/7d807754cc9153b04b599804464edd9654d7a81e/configurations/WFT%20Baseboard.json#L1678.
We use it specifically so we can use 1 binary for multiple baseboards
assuming similar i2c topology. At a high-level view, it takes JSON and
when appropriate fields are available on d-bus, puts a system
configuration on d-bus, along with being able to export some i2c devices.
Hope this helps
-James
next prev parent reply other threads:[~2019-12-12 15:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-03 12:06 Faking Sensor Readings rgrs
2019-12-03 13:49 ` Alexander Amelkin
2019-12-03 20:04 ` James Feist
2019-12-04 9:39 ` rgrs
2019-12-04 17:10 ` James Feist
2019-12-06 11:32 ` rgrs
2019-12-09 18:28 ` James Feist
2019-12-11 9:14 ` rgrs
2019-12-11 17:29 ` James Feist
2019-12-12 5:28 ` rgrs
2019-12-12 15:57 ` James Feist [this message]
2019-12-13 6:06 ` rgrs
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=8cef3ef8-a275-2f36-dfeb-7b4da97c6f88@linux.intel.com \
--to=james.feist@linux.intel.com \
--cc=a.amelkin@yadro.com \
--cc=openbmc@lists.ozlabs.org \
--cc=rgrs@protonmail.com \
--cc=richard.marian.thomaiyar@linux.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.