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

[Jean Delvare]

David,

On Fri, 2 Mar 2007 10:44:38 -0800, David Brownell wrote:
> 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.

This is correct, but not specific to the SMBus quick command. I2C
doesn't have any semantics at all, SMBus adds them at the same time it
restricts the set of allowed transactions.

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

I pretty much doubt that systems branded "I2C" need to support any
semantics at all, given that the I2C specification doesn't have such
semantics in the first place. So again I fail to see how the
zero-length transaction, aka SMBus quick command, is special in that
respect, other than in your personal experience that some bus master
chips happen to not support it (which can be explained by the simple
fact that a zero-length command seems useless at first sight.)

Also note that SMBus chips do not have to support the SMBus quick
command either, and in fact I don't remember any which explicitly
supported it. They just happen to support at least one transaction type
which begins with the exact same sequence, so they can't make the
difference and ack it.

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

True, this is one of the problematic cases, but this is really a
misimplementation of the I2C standard in the first place (not detecting
the stop condition on the bus.) This is definitely related to the fact
that the designers did not expect the zero-length transaction, granted,
but it doesn't make such a transaction less valid with regards to the
I2C specification.

-- 
Jean Delvare