OEM i2c over IPMI

[Peter Hanson]

On Tue, Oct 2, 2018 at 8:31 PM Patrick Venture <venture at google.com> wrote:

> +peterh@
>
> I believe it was a more flexible approach.
>
> Patrick
> On Tue, Oct 2, 2018 at 3:39 PM Tanous, Ed <ed.tanous at intel.com> wrote:
> >
> > > -----Original Message-----
> > > From: openbmc [mailto:openbmc-
> > > bounces+ed.tanous=intel.com at lists.ozlabs.org] On Behalf Of Patrick
> > > Venture
> > > Sent: Tuesday, October 2, 2018 1:00 PM
> > > To: OpenBMC Maillist <openbmc at lists.ozlabs.org>
> > > Subject: OEM i2c over IPMI
> > >
> > > We have a linux kernel driver for i2c-via-ipmi that ties into
> > > https://gerrit.openbmc-project.xyz/12604 - I'm putting this upstream
> but
> > > since it's an IPMI OEM handler, it can nicely go into its own
> repository - I was
> > > curious if there was any OpenBMC interest?  If so, we can aim for the
> > > phosphor namespace, otherwise I'll just ask that it be pushed into a
> google
> > > repo.
> > >
> >
> > What does this command do that the existing master write-read command
> (section 22.11 of the IPMI spec) doesn't?
>

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.


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

Example use case: detect a card type, then instantiate implied Linux I2C
devices on the associated proxy bus for smbus to that slot.

Yes, also smashes 8 bus limit.


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

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 ;^)

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.

Arguably most useful as a bridging/prototyping tactic; then moving
interesting accesses into BMC for better stability at volume.


> > -Ed
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20181003/33932238/attachment.html>