“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.

“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.

-Ed

-----Original Message-----
From: openbmc [mailto:openbmc-bounces+ed.tanous=intel.com@lists.ozlabs.org] On Behalf Of Brad Bishop
Sent: Monday, October 23, 2017 12:17 PM
To: "David Müller (ELSOFT AG)" <d.mueller@elsoft.ch>
Cc: OpenBMC <openbmc@lists.ozlabs.org>
Subject: Re: PECI API?

> On Oct 21, 2017, at 4:57 AM, David Müller (ELSOFT AG) <d.mueller@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@google.com]
Sent: Monday, October 23, 2017 12:02 PM
To: Tanous, Ed <ed.tanous@intel.com>
Cc: David Müller (ELSOFT AG) <d.mueller@elsoft.ch>; OpenBMC <openbmc@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@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@lists.ozlabs.org] On Behalf Of David Müller (ELSOFT AG)
Sent: Saturday, October 21, 2017 1:57 AM
To: OpenBMC <openbmc@lists.ozlabs.org>
Subject: PECI API?

Hello

Is anyone working on an API definition for PECI?


Dave