<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Oct 2, 2018 at 8:31 PM Patrick Venture <<a href="mailto:venture@google.com">venture@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+peterh@<br>
<br>
I believe it was a more flexible approach.<br>
<br>
Patrick<br>
On Tue, Oct 2, 2018 at 3:39 PM Tanous, Ed <<a href="mailto:ed.tanous@intel.com" target="_blank">ed.tanous@intel.com</a>> wrote:<br>
><br>
> > -----Original Message-----<br>
> > From: openbmc [mailto:<a href="mailto:openbmc-" target="_blank">openbmc-</a><br>
> > bounces+ed.tanous=<a href="mailto:intel.com@lists.ozlabs.org" target="_blank">intel.com@lists.ozlabs.org</a>] On Behalf Of Patrick<br>
> > Venture<br>
> > Sent: Tuesday, October 2, 2018 1:00 PM<br>
> > To: OpenBMC Maillist <<a href="mailto:openbmc@lists.ozlabs.org" target="_blank">openbmc@lists.ozlabs.org</a>><br>
> > Subject: OEM i2c over IPMI<br>
> ><br>
> > We have a linux kernel driver for i2c-via-ipmi that ties into<br>
> > <a href="https://gerrit.openbmc-project.xyz/12604" rel="noreferrer" target="_blank">https://gerrit.openbmc-project.xyz/12604</a> - I'm putting this upstream but<br>
> > since it's an IPMI OEM handler, it can nicely go into its own repository - I was<br>
> > curious if there was any OpenBMC interest?  If so, we can aim for the<br>
> > phosphor namespace, otherwise I'll just ask that it be pushed into a google<br>
> > repo.<br>
> ><br>
><br>
> What does this command do that the existing master write-read command (section 22.11 of the IPMI spec) doesn't?<br>
</blockquote><div><br></div><div><div>Kernel driver provides host side proxy for BMC bus. As such, it supports *general* multi-step smbus/i2c transfers. E.g., pmbus devices with variable read length.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> I know on past systems we've offered the OEM I2C command to get around the 8 channel limit for the stock command.  I can't tell if that's the case with this one, but we should probably have a statement on exactly what we're trying to solve compared to the IPMI master write read.<br>
</blockquote><div><br></div><div>Example use case: detect a card type, then instantiate implied Linux I2C devices on the associated proxy bus for smbus to that slot.</div><div><br></div><div>Yes, also smashes 8 bus limit.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> It should also be noted that master write-read opens up some pretty scary security scenarios, especially when done over IPMI.  We should probably make sure it's isolated to its own library so the high security systems can opt out of it if need be.<br>
</blockquote><div><br></div><div>Oh, indeed! Should be restricted. (Root on local host, perhaps?) Suggest to make it opt-in. With red hazard label if that can be done ;^)</div><div><br></div><div>Another down-side: i2c/smbus is already flakey and error prone in interesting scenarios. (Something going wrong, trying to figure out what.) Adding another protocol layer in the middle can hurt stability.</div><div><br></div><div>Arguably most useful as a bridging/prototyping tactic; then moving interesting accesses into BMC for better stability at volume.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> -Ed<br>
</blockquote></div></div>