Re: [PATCH v2 0/4] ipmi: bt-i2c: added IPMI Block Transfer over I2C

From: Corey Minyard
Date: Sat Aug 05 2017 - 18:23:52 EST

On 08/04/2017 08:18 PM, Brendan Higgins wrote:
This patchset introduces IPMI Block Transfer over I2C (BT-I2C), which has the
same semantics as IPMI Block Transfer except it done over I2C.

For the OpenBMC people, this is based on an RFC:

The documentation discusses the reason for this in greater detail, suffice it to
say SSIF cannot be correctly implemented on some naive I2C devices. There are
some additional reasons why we don't like SSIF, but those are again covered in
the documentation for all those who are interested.

I'm not terribly excited about this. A few notes:

SMBus alerts are fairly broken in Linux right now. I have a patch to fix this at:
I haven't been able to get much traction getting anyone to care.

The lack of a NACK could be worked around fairly easily in the current driver. It looks like you
are just returning a message too short to be valid. That's easy. I think it's a rather major
deficiency in the hardware to not be able to NACK something, but that is what it is.

What you have is not really BT over I2C. You have just added a sequence number to the
IPMI messages and dropped the SMBus command. Other interfaces have sequence numbers,
too. Calling it BT is a little over the top.

Do you really need the performance required by having multiple outstanding messages?
That adds a lot of complexity, if it's unnecessary it's just a waste. The IPMI work on top
of interfaces does not really require that much performance, it's just reading sensors,
FRU data, and such. Perhaps you have a reason, but I fail to see
why it's really that big a deal. The BT interface has this ability, but the driver does not
take advantage of it and nobody has complained.

And I don't understand the part about OpenBMC making use of sequence numbers.
Why does that matter for this interface? It's the host side that would care about
that, the host would stick the numbers in and the slave would return it. If you are
using sequence numbers in OpenBMC, which sounds quite reasonable, I would think
it would be a bad idea to to trust that the host would give you good sequence

Plus, with multiple outstanding messages, you really need to limit it. A particular BMC
may not be able to handle it the full 256, and the ability to have that many messages
outstanding is probably not a good thing.

If you really need multiple outstanding messages, the host side IPMI message handler
needs to change to allow that. It's doable, and I know how, I just haven't seen the

I would agree that the multi-part messages in SSIF is a big pain and and a lot of
unnecessary complexity. I believe it is there to accommodate host hardware that is
limited. But SMBus can have 255 byte messages and there's no arbitrary limit on
I2C. It is the way of IPMI to support the least common denominator.

Your interface will only work on Linux. Other OSes (unless they choose to implement this
driver) will be unable to use your BMC. Of course there's the NACK issue, but that's a
big difference, and it would probably still work with existing drivers on other OSes.
Plus people may choose to use OpenBMC on things besides the aspeed devices that
could do a NACK. That's kind of the point of OpenBMC, isn't it?

My suggestion would be to implement a BMC that supports standard SSIF single part
messages by default. That way any existing driver will work with it. (I don't know
about the NACK thing, but that's a much smaller issue than a whole new protocol.)
Then use OEM extensions to query things like if it can do messages larger than 32
bytes or supports sequence numbers, and how many outstanding messages it
can have, and extend the current SSIF driver. It wouldn't be very hard.

In my experience, sticking with standards is a good thing, and designing your own
protocols is fraught with peril. I'm not trying to be difficult here, but I am against
the proliferation of things that do not need to proliferate :).


In addition, since I am adding both host side and BMC side support, I figured
that now is a good time to resolve the problem of where to put BMC side IPMI
drivers; right now we have it (there is only one) in drivers/char/ipmi/ with the
rest of the host side IPMI drivers, but I think it makes sense to put all of the
host side IPMI drivers in one directory and all of the BMC side drivers in
another, preferably in a way that does not effect all of the current OpenIPMI
users. I have not created a MAINTAINERS entry for the new directory yet, as I
figured there might be some discussion to be had about it.

I have tested this patchset on the Aspeed 2500 EVB.

Changes since previous update:
- Cleaned up some documentation.
- Added patch which moves the Aspeed BT-BMC driver to the new ipmi_bmc