From: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
To: Derek Lin23 <dlin23@lenovo.com>,
"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Cc: Duke KH Du <dukh@lenovo.com>,
Andrew MS1 Peng <pengms1@lenovo.com>,
Harry Sung1 <hsung1@lenovo.com>,
Haitao HT11 Wang <wanght11@lenovo.com>,
Yonghui YH21 Liu <liuyh21@lenovo.com>,
Lisa YJ19 Liu <liuyj19@lenovo.com>
Subject: Re: One question is regarding of PECI driver.
Date: Wed, 19 Jun 2019 09:31:10 -0700 [thread overview]
Message-ID: <b01e1e4e-e723-bae2-32e0-20b47d38efcf@linux.intel.com> (raw)
In-Reply-To: <1616aac7ca904100be2e0a7dddcc6127@lenovo.com>
On 6/14/2019 2:24 AM, Derek Lin23 wrote:
> Hi team:
>
> We have a question for PECI driver, hope we can have some
> inputs and feedbacks.
>
> When PECI driver starts, it checks the availabilities for
> CPUs by the addresses defining in the device tree.
Yes, it's what PECI driver does.
> But, when none of the CPUs are available, in our cases, CPUs
> are powered off, PECI driver responses with error messages of PECI
> clients and devices are not registered.
It's an expected result because PECI works only when the host CPU is
powered on.
> Is it possible that PECI driver would listen the events for
> power-on? So, PECI driver would be reloaded and PECI clients and devices
> become available.
No. Instead, we are using CPU ping from user space and register PECI
clients at run time. Please check these services:
https://github.com/openbmc/dbus-sensors
https://github.com/openbmc/entity-manager
Thanks,
Jae
> Or, other thoughts and ideas?
>
> Thank you,
>
>
> Derek Lin
>
prev parent reply other threads:[~2019-06-19 16:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-14 9:24 One question is regarding of PECI driver Derek Lin23
2019-06-19 16:31 ` Jae Hyun Yoo [this message]
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=b01e1e4e-e723-bae2-32e0-20b47d38efcf@linux.intel.com \
--to=jae.hyun.yoo@linux.intel.com \
--cc=dlin23@lenovo.com \
--cc=dukh@lenovo.com \
--cc=hsung1@lenovo.com \
--cc=liuyh21@lenovo.com \
--cc=liuyj19@lenovo.com \
--cc=openbmc@lists.ozlabs.org \
--cc=pengms1@lenovo.com \
--cc=wanght11@lenovo.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.