[i2c] [patch 3/5] i2c probe() and remove(), documented at last

[David Brownell]

On Friday 02 March 2007 9:40 am, Jean Delvare wrote:

> >  Some adapters understand only the SMBus (System Management Bus) protocol,
> > -which is a subset from the I2C protocol. Fortunately, many devices use
> > -only the same subset, which makes it possible to put them on an SMBus.
> > +which largely overlaps the I2C protocol.  SMBus has some mechanisms that
> > +I2C doesn't, like SMBUS_QUICK; and vice versa.  The electrical constraints
> > +are also different.  Conveniently, many I2C devices use a subset of the I2C
> > +protocols and signaling which is SMBus-compatible.
> 
> The SMBus protocol is really a subset of the I2C protocol. What SMBus
> calls "Quick Command" is a perfectly valid I2C transaction, even though
> you keep saying otherwise. 

However, SMBUS assigns specific semantics to it which make it safe to
issue to arbitrary devices ... where I2C doesn't define semantics for
those messages, which makes it a "pray nothing breaks" kind of issue
on systems advertising I2C conformance rather than SMBUS conformance.


> Whether all I2C bus masters support it or 
> not is an entirely different matter, and whether or not I2C chips
> support it or not is yet a different matter.

The reason I wrote "overlaps" is that while, as you observe, the bits
exchanged for SMBUS_QUICK do fit within the I2C space, the semantics
assigned to them (by SMBus) are an extension ... not mandatory.  So
while there are I2C transactions SMBUS doesn't include, likewise there
are SMBUS semantics that I2C doesn't include.

Another way to put this is to observe that systems branded "I2C" (it's
a trademark/brand, not all vendors are licensed to say they conform!)
are not required to support SMBUS_QUICK semantics.


> * EEPROMS are I2C chips, and most of them ack the "SMBus quick
>   command" (zero-length message) just fine.

But then there are those nasty cases like the 24RF08 EEPROMs,
where SMBUS_QUICK by itself triggers corruption problems ...

- Dave