PECI API?

[Rick Altherr]

On Mon, Oct 23, 2017 at 12:39 PM, Tanous, Ed <ed.tanous at intel.com> wrote:

> “Rather than a PECI API, would it make any sense to define a an abstract
> concept API, where one implementation of it has a PECI backend?”
>
>
>
> I don’t think so, but that’s partially why I asked about use cases.  PECI
> can be thought of a lot like SMBus, with some fancy protocol level features
> that make it easier to implement.  It’s a generic interface that can be
> used for any number of things, including temperature readings from
> processors and memory.  Our intention was to implement it as a device
> driver (/dev/peci), with (one or several) dbus daemons reading and pushing
> information to dbus using the existing openbmc interfaces (sensor,
> threshold, logging ect).  There was also talk of implementing it as a hwmon
> driver, but I think that discussion was deferred, given that the number of
> “sensors” needs to be determined at runtime, and that didn’t seem to fit in
> the hwmon model.  This work is ongoing, so I don’t have a timeframe on
> completion or its level of robustness, but if there’s interest, I can
> probably push the WIP to a branch or a repo somewhere.
>
>
>

hwmon has APIs for dynamically adding sensors at runtime.  For temps,
volts, etc, I prefer an hwmon driver built atop a PECI subsystem.


> “Is there a kernel subsystem for PECI defined upstream?  I'm not aware of
> a PECI device driver for Aspeed upstream.”
>
> I don’t believe there is one defined upstream, but I believe the first
> revision of the driver code we are using was derived from the Aspeed SDK.
>

What happens when Nuvoton sends their driver?


>
>
> -Ed
>
>
>
>
>
> -----Original Message-----
> From: openbmc [mailto:openbmc-bounces+ed.tanous=intel.com at lists.ozlabs.org]
> On Behalf Of Brad Bishop
> Sent: Monday, October 23, 2017 12:17 PM
> To: "David Müller (ELSOFT AG)" <d.mueller at elsoft.ch>
> Cc: OpenBMC <openbmc at lists.ozlabs.org>
> Subject: Re: PECI API?
>
>
>
>
>
> > On Oct 21, 2017, at 4:57 AM, David Müller (ELSOFT AG) <
> d.mueller at elsoft.ch> wrote:
>
> >
>
> > Hello
>
> >
>
> > Is anyone working on an API definition for PECI?
>
> >
>
> >
>
> > Dave
>
>
>
> Full disclosure - the Wikipedia article is the extent of my background on
> PECI.
>
>
>
> Rather than a PECI API, would it make any sense to define a an abstract
> concept API, where one implementation of it has a PECI backend?
>
>
>
> My cursory glance at the Wikipedia article suggests PECI provides
> temperature readings (I’m sure it does much more) but the basic thought
> process I’ve outlined would allow control applications or metric gathering
> applications, etc to be re-used irrespective of where the data is coming
> from.
>
>
>
> -brad
>
>
>
>
>
> *From:* Rick Altherr [mailto:raltherr at google.com]
> *Sent:* Monday, October 23, 2017 12:02 PM
> *To:* Tanous, Ed <ed.tanous at intel.com>
> *Cc:* David Müller (ELSOFT AG) <d.mueller at elsoft.ch>; OpenBMC <
> openbmc at lists.ozlabs.org>
> *Subject:* Re: PECI API?
>
>
>
> Is there a kernel subsystem for PECI defined upstream?  I'm not aware of a
> PECI device driver for Aspeed upstream.
>
>
>
> On Mon, Oct 23, 2017 at 9:44 AM, Tanous, Ed <ed.tanous at intel.com> wrote:
>
> We had looked at building one, and had one prototyped for a simple
> read/write interface, but we were on the fence about whether such a low
> level control (PECI read/write) should be put on dbus at all for security
> reasons, especially when the drivers read/write API isn't that difficult to
> use.
>
> What are you looking at doing with it?
>
> -Ed
>
>
> -----Original Message-----
> From: openbmc [mailto:openbmc-bounces+ed.tanous=intel.com at lists.ozlabs.org]
> On Behalf Of David Müller (ELSOFT AG)
> Sent: Saturday, October 21, 2017 1:57 AM
> To: OpenBMC <openbmc at lists.ozlabs.org>
> Subject: PECI API?
>
> Hello
>
> Is anyone working on an API definition for PECI?
>
>
> Dave
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20171023/99d2bbd5/attachment-0001.html>