<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.m5034264857258747810msoplaintext, li.m5034264857258747810msoplaintext, div.m5034264857258747810msoplaintext
{mso-style-name:m_5034264857258747810msoplaintext;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.m5034264857258747810hoenzb
{mso-style-name:m_5034264857258747810hoenzb;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Rick Altherr [mailto:raltherr@google.com]
<br>
<b>Sent:</b> Monday, October 23, 2017 12:48 PM<br>
<b>To:</b> Tanous, Ed <ed.tanous@intel.com><br>
<b>Cc:</b> David Müller (ELSOFT AG) <d.mueller@elsoft.ch>; OpenBMC <openbmc@lists.ozlabs.org><br>
<b>Subject:</b> Re: PECI API?<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Mon, Oct 23, 2017 at 12:39 PM, Tanous, Ed <<a href="mailto:ed.tanous@intel.com" target="_blank">ed.tanous@intel.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="m5034264857258747810msoplaintext"><span style="color:#1F497D">“</span>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?”<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">hwmon has APIs for dynamically adding sensors at runtime. For temps, volts, etc, I prefer an hwmon driver built atop a PECI subsystem.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">[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.<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">“</span>Is there a kernel subsystem for PECI defined upstream? I'm not aware of a PECI device driver
for Aspeed upstream.”<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">What happens when Nuvoton sends their driver?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">[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.<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">-Ed</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="m5034264857258747810msoplaintext">-----Original Message-----<br>
From: openbmc [mailto:<a href="mailto:openbmc-bounces%2Bed.tanous" target="_blank">openbmc-bounces+ed.tanous</a>=<a href="mailto:intel.com@lists.ozlabs.org" target="_blank">intel.com@lists.ozlabs.org</a>] On Behalf Of Brad Bishop<br>
Sent: Monday, October 23, 2017 12:17 PM<br>
To: "David Müller (ELSOFT AG)" <<a href="mailto:d.mueller@elsoft.ch" target="_blank">d.mueller@elsoft.ch</a>><br>
Cc: OpenBMC <<a href="mailto:openbmc@lists.ozlabs.org" target="_blank">openbmc@lists.ozlabs.org</a>><br>
Subject: Re: PECI API?<o:p></o:p></p>
<p class="m5034264857258747810msoplaintext"> <o:p></o:p></p>
<p class="m5034264857258747810msoplaintext"> <o:p></o:p></p>
<p class="m5034264857258747810msoplaintext">> On Oct 21, 2017, at 4:57 AM, David Müller (ELSOFT AG) <<a href="mailto:d.mueller@elsoft.ch" target="_blank"><span style="color:windowtext;text-decoration:none">d.mueller@elsoft.ch</span></a>> wrote:<o:p></o:p></p>
<p class="m5034264857258747810msoplaintext">> <o:p></o:p></p>
<p class="m5034264857258747810msoplaintext">> Hello<o:p></o:p></p>
<p class="m5034264857258747810msoplaintext">> <o:p></o:p></p>
<p class="m5034264857258747810msoplaintext">> Is anyone working on an API definition for PECI?<o:p></o:p></p>
<p class="m5034264857258747810msoplaintext">> <o:p></o:p></p>
<p class="m5034264857258747810msoplaintext">> <o:p></o:p></p>
<p class="m5034264857258747810msoplaintext">> Dave<o:p></o:p></p>
<p class="m5034264857258747810msoplaintext"> <o:p></o:p></p>
<p class="m5034264857258747810msoplaintext">Full disclosure - the Wikipedia article is the extent of my background on PECI.<o:p></o:p></p>
<p class="m5034264857258747810msoplaintext"> <o:p></o:p></p>
<p class="m5034264857258747810msoplaintext">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?<o:p></o:p></p>
<p class="m5034264857258747810msoplaintext"> <o:p></o:p></p>
<p class="m5034264857258747810msoplaintext">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.<o:p></o:p></p>
<p class="m5034264857258747810msoplaintext"> <o:p></o:p></p>
<p class="m5034264857258747810msoplaintext">-brad<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Rick Altherr [mailto:<a href="mailto:raltherr@google.com" target="_blank">raltherr@google.com</a>]
<br>
<b>Sent:</b> Monday, October 23, 2017 12:02 PM<br>
<b>To:</b> Tanous, Ed <<a href="mailto:ed.tanous@intel.com" target="_blank">ed.tanous@intel.com</a>><br>
<b>Cc:</b> David Müller (ELSOFT AG) <<a href="mailto:d.mueller@elsoft.ch" target="_blank">d.mueller@elsoft.ch</a>>; OpenBMC <<a href="mailto:openbmc@lists.ozlabs.org" target="_blank">openbmc@lists.ozlabs.org</a>><br>
<b>Subject:</b> Re: PECI API?</span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Is there a kernel subsystem for PECI defined upstream? I'm not aware of a PECI device driver for Aspeed upstream. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Mon, Oct 23, 2017 at 9:44 AM, Tanous, Ed <<a href="mailto:ed.tanous@intel.com" target="_blank">ed.tanous@intel.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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.<br>
<br>
What are you looking at doing with it?<br>
<span style="color:#888888"><br>
<span class="m5034264857258747810hoenzb">-Ed</span></span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
-----Original Message-----<br>
From: openbmc [mailto:<a href="mailto:openbmc-bounces%2Bed.tanous" target="_blank">openbmc-bounces+ed.tanous</a>=<a href="mailto:intel.com@lists.ozlabs.org" target="_blank">intel.com@lists.ozlabs.org</a>] On Behalf Of David Müller (ELSOFT AG)<br>
Sent: Saturday, October 21, 2017 1:57 AM<br>
To: OpenBMC <<a href="mailto:openbmc@lists.ozlabs.org" target="_blank">openbmc@lists.ozlabs.org</a>><br>
Subject: PECI API?<br>
<br>
Hello<br>
<br>
Is anyone working on an API definition for PECI?<br>
<br>
<br>
Dave<o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>