Re: PECI API?

[Rick Altherr <raltherr@google.com>]

On Mon, Oct 23, 2017 at 1:24 PM, Tanous, Ed <ed.tanous@intel.com> wrote:
>
>
>
>
> From: Rick Altherr [mailto:raltherr@google.com]
> Sent: Monday, October 23, 2017 12:48 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?
>
>
>
>
>
>
>
> On Mon, Oct 23, 2017 at 12:39 PM, Tanous, Ed <ed.tanous@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.
>
>
>
> [Ed]  I was personally unaware that hwmon itself had that capability.  We
> had previously implemented a dynamically generated device tree overlay that
> accomplished some of that for LM75 sensors.  I will point my developers at
> it.
>
> “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] ….. we work to build a common interface that meets everyone’s needs,
> while abstracting the hardware interfaces into the kernel.  Part of the
> issue with PECI is there are some userspace constructs (retries, framing,
> timing, ect) that are a part of the PECI specification, but could be pushed
> to either hardware abstractions, or userspace code.  Where they get
> implemented (for platforms I’ve been a part of) has thusfar been a matter of
> preference on the part of the developer.  We likely should get together a
> group of interested parties and see if we can come up with an interface that
> works for everyone.  I have not yet worked with a Nuvoton platform, so I’m
> sure I have quite a bit to learn in that space.
>
>

I know Google is interested in seeing this abstraction get developed
soon.  Ideally this abstraction goes in to upstream as part of the
same patch series as an Aspeed driver.

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