<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 23, 2017 at 12:39 PM, Tanous, Ed <span dir="ltr"><<a href="mailto:ed.tanous@intel.com" target="_blank">ed.tanous@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div class="m_5034264857258747810WordSection1">
<p class="m_5034264857258747810MsoPlainText"><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?”<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> </span></p></div></div></blockquote><div><br></div><div>hwmon has APIs for dynamically adding sensors at runtime.  For temps, volts, etc, I prefer an hwmon driver built atop a PECI subsystem.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_5034264857258747810WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u></span></p>
<p class="MsoNormal"><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.”<u></u><u></u></p>
<p class="MsoNormal"><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></p></div></div></blockquote><div><br></div><div>What happens when Nuvoton sends their driver?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_5034264857258747810WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">-Ed<u></u><u></u></span></p><span class="">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="m_5034264857258747810MsoPlainText">-----Original Message-----<br>
From: openbmc [mailto:<a href="mailto:openbmc-bounces%2Bed.tanous" target="_blank">openbmc-bounces+ed.<wbr>tanous</a>=<a href="mailto:intel.com@lists.ozlabs.org" target="_blank">intel.com@lists.ozlabs.<wbr>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?<u></u><u></u></p>
<p class="m_5034264857258747810MsoPlainText"><u></u> <u></u></p>
<p class="m_5034264857258747810MsoPlainText"><u></u> <u></u></p>
<p class="m_5034264857258747810MsoPlainText">> 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:<u></u><u></u></p>
<p class="m_5034264857258747810MsoPlainText">> <u></u><u></u></p>
</span><span class=""><p class="m_5034264857258747810MsoPlainText">> Hello<u></u><u></u></p>
<p class="m_5034264857258747810MsoPlainText">> <u></u><u></u></p>
<p class="m_5034264857258747810MsoPlainText">> Is anyone working on an API definition for PECI?<u></u><u></u></p>
<p class="m_5034264857258747810MsoPlainText">> <u></u><u></u></p>
<p class="m_5034264857258747810MsoPlainText">> <u></u><u></u></p>
<p class="m_5034264857258747810MsoPlainText">> Dave<u></u><u></u></p>
<p class="m_5034264857258747810MsoPlainText"><u></u> <u></u></p>
</span><p class="m_5034264857258747810MsoPlainText">Full disclosure - the Wikipedia article is the extent of my background on PECI.<u></u><u></u></p><span class="">
<p class="m_5034264857258747810MsoPlainText"><u></u> <u></u></p>
<p class="m_5034264857258747810MsoPlainText">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?<u></u><u></u></p>
<p class="m_5034264857258747810MsoPlainText"><u></u> <u></u></p>
<p class="m_5034264857258747810MsoPlainText">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.<u></u><u></u></p>
<p class="m_5034264857258747810MsoPlainText"><u></u> <u></u></p>
<p class="m_5034264857258747810MsoPlainText">-brad<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
</span><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:<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?<u></u><u></u></span></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Is there a kernel subsystem for PECI defined upstream?  I'm not aware of a PECI device driver for Aspeed upstream.  <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">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:<u></u><u></u></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">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="m_5034264857258747810hoenzb">-Ed</span></span><u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><br>
-----Original Message-----<br>
From: openbmc [mailto:<a href="mailto:openbmc-bounces%2Bed.tanous" target="_blank">openbmc-bounces+ed.<wbr>tanous</a>=<a href="mailto:intel.com@lists.ozlabs.org" target="_blank">intel.com@lists.ozlabs.<wbr>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<u></u><u></u></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>

</blockquote></div><br></div></div>