[RFC 0/2] misc: bt: added Block Transfer over I2C

[Brendan Higgins]

Looking for feedback on my new bt-i2c (Block Transfer over I2C) interface.

This is not a standard IPMI hardware interface. The IPMI specified hardware
interface for I2C/SMBus is SSIF (SMBus System Interface); however, SSIF is not a
very good solution for what we are trying to do:

First off, SSIF does not support sequence numbers, which makes multiple
in-flight messages difficult to implement (the IPMI spec explicitly leaves out
"multithreaded support" for SSIF, but does say it can be supported by an
implementor); this is a major issue for us as we would like to support multiple
in-flight messages. It also looks like OpenBMC makes use of the sequence number
in several places; on OpenBMC, it may be possible to address this by adding in a
sequence field to incoming SSIF messages that is always zero, but this would
not address the problem of multiple in-flight messages.

The second main limitation to SSIF is that it requires the slave side (BMC) to
NACK until it is ready to either send or receive data (technically this is not a
hard requirement, but the spec does say the BMC must NACK until ready to provide
a response unless SMBus Alert is available/enabled; this is effectively a
requirement because SSIF allows SMBus Alert to be turned off and is to be turned
off by default). However, the Aspeed 24XX and Aspeed 25XX I2C controllers do not
support arbitrary NACKing in slave mode; the only way to NACK is to disable
slave mode, which would also prevent the slave from responding to incoming
messages when it is unable to provide an outgoing message.

Although we could modify SSIF to suit our needs, some of the desired
modifications would be substantial (such as adding in a sequence field; it would
completely change the framing of the message); so I decided that SSIF was
probably not the best route to go for IPMI over I2C.

Here I introduce the bt-i2c (Block Transfer over I2C) interface; it is designed
such that it can be supported by any I2C slave device (using the standard Linux
I2C core slave mode framework), but I designed it such that it can make use of
SMBus Alert to notify the master (CPU) of available responses (not in this patch
set because it requires a change to I2C core; I was planning on using this
driver as the initial user). I wrote a precise specification of bt-i2c in the
second patch.

I based the slave side (BMC) driver on the bt-host driver; the file system
interface is fully compatible and has been tested with btbridged and ipmid
running on an ast2500 evb.

Work still to do:
 - Add support for SMBus Alert (currently in progrees).
 - Support O_NONBLOCK on the master side; I was planning on having this depend
   on SMBus Alert support since polling is required if it is not available.
 - Because bt-host and bt-i2c-slave share an identical file system interface; I
   was thinking that we could pull the file system interface out so that they
   share a single one.

Cheers!